Web UIs should have been procedural from the start, but HTML's design confused semantics and visualisation. CSS was supposed to clarify this, but CSS isn't procedural either. So js was added to the mix to fill the gaps in what CSS can't do. But js doesn't componentise well, so React was invented as yet another layer to "simplify" everything else.
So now we have a "proper" frontend dev language which sits on top of a virtual DOM which is still based on HTML etc.
All of this could have been avoided by making Web 1.0 procedural and explicitly extensible and not baking content styling into HTML's semantics. There would have been some small additional complexity and it might have been harder for beginners to learn initially. But the current stack is far beyond non-developers anyway.
I suspect there would have been at least a fighting chance of replacing everything with a single standard library that runs faster and could easily handle everything React does more simply and elegantly, including resolution-dependent rendering - probably something like iOS/Android, but even simpler, and using the browser explicitly as a VM/secure container.
HTML is nothing more than grouping definition of DOM elements. One of possible ways of defining element agglomerations.
It is not bad or good, it just allows to make job done - to group (semantically link) DOM elements together.
But the DOM element itself is what makes the difference. DOM element is the atomic block that a) can be attributed, b) may have states c) to be styled according to those attributes and states and d) can receive events.
In that respect Web UI is more granular than desktop UI. On desktop you have windows (NSViews, GtkWidgets, etc) that are macro state machines. E.g. COMBOBOX, LISTVIEW that have predefined complex structures and expose quite few configuration options|styles.
Web UI components are usually composed from many individually accessible and configurable DOM elements.
And that creates an impression of Web UI complexity. But in fact Web UI is just a DOM element with styles and bunch of layout managers to replace those DOM elements - its vocabulary is conceptually simpler and more regular than desktop macro blocks.
ReactJS (PReact, Mithril, Vue, etc) are not more than reactive DOM element aggregators - definitions of runtime assemblage of those LEGO bricks (DOM elements) in response of state/attributes changes.
On top of those we have Web UI frameworks that are all about providing sets of components - predefined types of aggregates of DOM elements.
So now we have a "proper" frontend dev language which sits on top of a virtual DOM which is still based on HTML etc.
All of this could have been avoided by making Web 1.0 procedural and explicitly extensible and not baking content styling into HTML's semantics. There would have been some small additional complexity and it might have been harder for beginners to learn initially. But the current stack is far beyond non-developers anyway.
I suspect there would have been at least a fighting chance of replacing everything with a single standard library that runs faster and could easily handle everything React does more simply and elegantly, including resolution-dependent rendering - probably something like iOS/Android, but even simpler, and using the browser explicitly as a VM/secure container.