[policy, no patch] Require Node.js for a future Drupal major version and rewrite some of Drupal's UI code from PHP to JS

Problem/Motivation

For background on progressively decoupling Drupal during 8.x, read Dries' blog post and #2645250: [META] Start using reactive declarative JS programming for some new core admin UIs → . In this issue, however, I'd like to explore what Drupal 9 might look like and how to get there.

In my opinion, Nicholas C. Zakas' post from 2013, Node.js and the new web front-end, is exactly correct in identifying that much of the web's (including Drupal's) current architecture of JS for client-side UI and PHP for server-side UI plus business logic (diagram) is not conducive to building great UIs, because it splits the UI code of a single website into two languages and results in barriers to front-end developers "owning" the server-side portion.

Proposed resolution

That blog post proposes that a better architecture is for client-side JS UI code to communicate over HTTP to server-side JS UI code and for that in turn to communicate over HTTP to PHP business logic code (diagram). I agree with that proposal, and furthermore, propose that it's time for Drupal to migrate to that architecture, which means:

1. Make Node.js a hosting requirement for Drupal 9. It's already the case that you can find cheap (e.g., $5/mo) Node.js hosting plans (https://www.openshift.com/ even has some free ones), and I think the options will significantly increase in the 3 or so years between now and Drupal 9's release, especially with Wordpress's recent release of Calypso, which might result in a market of millions of small website owners out there for mass hosting providers to want to attract.
2. Pick a JS framework to start rewriting some core UI code with. See #2645250: [META] Start using reactive declarative JS programming for some new core admin UIs → . Note that it's entirely possible that whatever is picked in 2016 won't end up being the one we want to use for Drupal 9's release. That's ok. Just like during Drupal 8's development, we started WYSIWYG development with Aloha editor, then switched to CKEditor once that became better suited to Drupal's needs. But we need to pick something to start the process with.
3. #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1 → proposes to minimize the delta between 9.0 and 8.LAST, perhaps going as far as making 8.LAST contain everything that 9.0 contains such that 9.0 is solely the removal of BC layers from 8.LAST, much like Symfony 3.0/2.8. Therefore, if we want to apply that approach to this issue, we'd need to figure out how to get incremental pieces into minor version of 8 that are optional. That would also allow people with Node.js on their server to start using the Node.js-driven UIs within their 8.x sites. And then in 9.0.0, we can remove the old PHP-based UIs.
4. #1804488: [meta] Introduce a Theme Component Library → , #1843798: [meta] Refactor Render API to be OO → , and 🌱 Evaluate Symfony form component as a replacement for Drupal FAPI Postponed: needs info are issues about modernizing things in the theme, render, and form systems that we didn't get to for 8.0.0. What I'm basically suggesting in this proposal is that we do that modernizing in Node.js rather than in PHP.

Remaining tasks

• Discuss this proposal to see if it has sufficient community buy-in.
• If it does, create an initiative to organize this huge undertaking, similar to Drupal 8's Configuration Management and other initiatives.

User interface changes

TBD

API changes

TBD

Data model changes

TBD