What is this "higher abstraction level"? The frameworks are trying to solve components, and they're doing it by introducing a needlessly complex API. All you need is a template library like Handlebars and you're mostly set. For an SPA, a routing library like PageJS (https://visionmedia.github.io/page.js/) should have you covered. If you prefer server-side rendering over SPA, just use jQuery-Pjax to get all the speed advantages of an SPA and all the SEO advantages of server-side rendering.
I think "just a template library" would re-render the complete DOM for every update, or require you to manually wire up all components. The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude.
That's if you use your template library to emulate React. What jQuery brings to the table is that you can sprinkle in a few selectors, event listeners and ajax calls, then you have no need for a shadow dom.
The minimal transform is usually trivial to implement by hand:
Not only is this technique significantly more flexible than react, there's no magic about it so it's far easier to reason about when things aren't working.
I am genuinely curious what percentage of web apps are demonstrably affected by "slow DOM updates" of several orders of magnitude.
You realize React solves a performance problem that it imposes on itself, due to immutability, right?
Pre-react web apps to do attempt to re-render the entire page root on every press of a key. They simply handle events and remove/add/update the specific DOM nodes that are appropriate.
remember appendChild() and removeChild() ? These are quite fast.
Usually I've experienced the performance issues with poor event handling (at the control level) on grid-like views...
That said, I like React's component structure... it works with me more than most. Though I tend to dev against react and build against preact-compat for reduced size. Which iirc uses real dom as point of truth.
The main take away from React is flux-like state management (ie Redux)... this is what helps with the real pain of larger apps (especially MVC) and that is cross-cutting concerns and state management. This is why Redux has been adopted, or roughly copied to all the up and coming options.
O.K., these organizational/structural concerns are fine, but are not what my point is addressing, which was OPs motivation of React on performance grounds.
Yes, grids seem to always be a problem. This is one of those 'sticky wickets' (for frameworks too!). Of course it can be solved, but i'm more interested in the general case here.
The problem with that is then you end up with the same horrible mess of event handlers all mutating global shared state. That's the same problem you have in most C# and Java UI programmes too.
yes, "They simply handle events and remove/add/update the specific DOM nodes that are appropriate." is intended as a clarification as to why DOM updates in this style are FAST. I am not intending with that statement for it to serve any purposes about code clarity or structure. (Which i think is clear in the context of what I wrote in the same paragraph, and what I am responding to.)
I am specifically responding to this:
The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude."
Of course you can take isolated sentences from me and purport alternate motivations (code clarity) to them so that you can make a new argument against that alternate motivation, but that is a different conversation.
I am in total agreement with you. I am rarely updating more than a handful of DOM nodes in a pass. I don't need a diffing algorithm to tell me which ones are gonna change.
