Web Components will fulfil the promise of Modular XHTML
While HTML has evolved, the authoring experience has not. CSS and JavaScript have evolved as specifications, but the notable fact is the tooling for these have progressed radically. Professional web developers now produce their CSS with preprocessors (SASS and LESS) and for JavaScript there is an ever increasing number frameworks and architectures.
Some developers choose to use languages such as HAML or Jade to generate their HTML, but this is essentially writing something that is then transformed to HTML - the level of sophistication of these generators can not mach the CSS and JS tooling available to the modern web developers today.
Commonly spread dynamic content management tools with templating languages such as Twig and Handlebars have made authoring HTML more efficient and less tedious. The thing is that these tools have very little to do with HTML itself.
Advancing the hypertext markup language standards to be more atomic is a need that has been acknowledged by the web standards bodies years ago. In the early 2000s XHTML Modularisation promised to make HTML extensible:
XHTML modularization is a methodology for producing modularized markup languages in a number of different schema languages (currently DTDs, XML Schema and Relax NG) so that the modules can easily be plugged together to create markup languages.
This effort did not take hold and was pushed aside together with the XHTML standard itself with the return to HTML tagsoup. Maybe due to the creation complexity or just the fact that... they were of very little use to most developers and projects.
Fast forward to today where browsers are better than ever, web applications rival desktop apps in complexity and very few people bother to validate their markup for XML conformance. We've got hundreds of front end frameworks to manage the complexity of our applications and widgets, but as developers still need to keep in mind that the browser is still essentially handling a single document.
This is why the venerable iFrame is still the king of integration technologies. There was no rivalling method for reliably scoping and isolating individual sections of a website. For the last few years we've had the promise of Web Components revolution has been looming for a few years now:
Web Components consists of several separate technologies. You can think of Web Components as reusable user interface widgets that are created using open Web technology. They are part of the browser and so they do not need external libraries like jQuery or Dojo. An existing Web Component can be used without writing code, simply by adding an import statement to an HTML page. Web Components use new or still-developing standard browser capabilities.
With Web Components and polyfills we can fullfill the Modular XHTML promise in a pragmatic way. There are plenty of polyfills such as Polymer, X-Tags and Bosonic. I recommend you see them for yourself.
Also worth noting the actual method does not matter - if we'll use React or some other way to achieve the essence of this. It'll be advancement. In fact, if you're interested you can start today: Build a Web Component with Riot.js and Yandex Maps
I for one, look forward to copy-pasting widgets that will be a part of my "web document" without worries of leaking CSS styles, conflicting JavaScript variable names and need of considering cross site communications.
Web Components will deliver - in one way or another. Maybe standards will have to follow implementations.
Read the Microsoft Edge developer blog article on Web Components for more!