3 ms·
The reason VDOM was desirable is that React's "View is the function of the State" paradigm has a great developer experience, and VDOM was just the easiest way t
by hbrn 4y ago
The reason VDOM was desirable is that React's "View is the function of the State" paradigm has a great developer experience, and VDOM was just the easiest way to implement it without sacrificing performance too much.
Now that we played with the easiest implementation of V = f(S) for a few years, we're moving on to more complex implementations, which have their own benefits. Namely, less overhead and better DX.
Frameworks like Svelte are moving good chunk of state management accidental complexity out of your app code and into the framework itself, where it actually belongs (i.e. where it is essential).
- Izkata 4y ago> and VDOM was just the easiest way to implement it without sacrificing performance too much. Kind of. Virtual DOM nodes are extremely lightweight compared to real DOM nodes, so manipulating a VDOM to determine what updates need to be done to the DOM, instead of doing all interactions/comparisons directly with the DOM, had a big performance boost.
- hbrn 4y agoNo offense, but this sounds like typical React-cult nonsense. You're still making the same amount of DOM manipulations in the end. And you don't need VDOM to figure out which manipulations are necessary. There are some potential optimizations VDOM can allow (e.g. batching/deduping), but there's nothing "lightweight" about it. Lightweight overhead is still overhead.
- Izkata 4y agoWhen we started using React in 2015 it was in one of the official explanations (or semi-official, like a blog post by someone working on it). The page I remember involved comparing the number of attributes each node has in the vDOM vs the real DOM and its legacy attributes, and was about both about memory usage and how it restricts the search space by just not allowing most of those legacy attributes.