These standards exist to define and shape the capabilities that are at everyone’s disposal.
The whole point of a tool is to abstract away a concept that is not necessary to understand fulfill a job.
Not all abstractions are created equal.
Many of them aren’t even useful.
In particular React’s abstraction is entirely based on JavaScript, in effect isolating the developer from the browser’s other powerful capabilities of parsing and processing server delivered HTML and CSS.
In fact the browser’s priorities are
- Parsing and flowing the server delivered HTML markup
- Parsing the server delivered CSS and laying out the markup
- Parsing the JavaScript and initializing it.
i.e. JavaScript is the very last of it’s worries and yet JavaScript frameworks are acting as if JavaScript is “king of the hill” inside the browser.
The order of these priorites is based on the web browser’s fault tolerance model:
- Content is the foundation
- Markup is an enhancement
- Visual design is an enhancement
- Interaction is an enhancement
- The network is an enhancement (Service Worker API / Offline First)
(Note that minimal server-interactivity is guaranteed with just markup via forms.)
So to get around the isolation of React’s abstractions it has become necessary to introduce runtime JavaScript-based SSR on the server in order to take advantage of the browser’s strengths - parsing and processing of server delivered HTML and CSS.
So by abstracting “the gross” of the browser away, React has created additional complexity elsewhere, in the process constraining how React applications can be constructed in order to be able to use SSR and for the most part dictating that JavaScript has to be used on the server side for rendering.
Meanwhile React’s abstraction relies for the most part on the presence of a VDOM which at first seemed like a brilliant move (some disagree) but the VDOM will likely become a hinderence in the future.
Furthermore the SPA model (and Elm is in this camp as well) is just one of a whole spectrum of ways to construct web applications.
Flash was successful for a time to some degree because it made the browser irrelevant for flash developers.
But is Flash (Java Applets, ActiveX, Silverlight) relevant now? HTML, CSS, ES and the browsers survived them all - and meanwhile the Web Standards have evolved with them.
Similarly the SPA model with it’s server-side JavaScript SSR may simply become a blip in the history of the web.
To my mind Svelte 3 is pointing in the right direction but as such is still flawed as it is an entirely JavaScript focused technology. The logical extension is a tool that outputs not just JavaScript but also platform independent templates for (initial) server rendered HTML and the supporting CSS.
However that requires a team that is much larger than the Svelte team and will likely result in a suite of tools that will rival Eclipse and Visual Studio (not Visual Studio Code but the commercial product) ecosystem. Whether and when we’ll arrive at that point is anybody’s guess.
But even then developers will still complain - for example, if the tool enforces accessibility standards - why they have to concern themselves with all this other nonsense - they just want to built their application and be done with it.
It’s simple enough to avoid the browser - stick to native apps.
However everybody wants to leverage the universal reach of the web and browsers (HTML/CSS/JS/WebAssembly) are an integral part of that reach, so they get to dictate the terms.
Sure, Browsers are D**ks (in the words of Jake Archibald) but the Web Standards lets you take advantage of them to maximal effect - for the most part.
