As all articles say the Virtual DOM is lightweight and allows us to update only those nodes that has to be updated, unlike the real DOM that updates the whole nodes structure.
So the first question: how is Virtual DOM lightweight? Since it can’t affect the nodes structure I assume VDOM does not have some methods that the real one has (like .createElement). If I’m wrong then what make the VDOM lightweight?
Second question: how does VDOM make the real DOM update only necessary elements? Why does DOM not do that itself? Since VDOM can’t affect the nodes structure it will eventually ask the real DOM do all the necessary updates.
If the real DOM is able to update only necessary parts of the whole structure then why do we need the VDOM? Why isn’t it a built-in DOM behaviour?
Some articles say that the VDOM accumulates updates and then rerender the whole DOM at once. While the real DOM updates the whole nodes structure right away everytime something changes the structure. So VDOM would change 5 element in one update while real DOM would need 5 updates to change 5 elements.
If VDOM works like this then why does it traverse the whole structure and tag nodes that has to be updtaed? Why not just wait until there is no more changes to the structure and just update the whole DOM? Not traversing and tagging nodes?
Would really appreciate if you explain this to me in details or give me some links to in-depth articles/videos on this topic.
6
Virtual DOM solves the problem of aggressive re-rendering. Newer frameworks know how to know which state changes are relevant to which DOM nodes, making the Virtual DOM approach redundant.
Before React & Friends, popular frameworks and libraries were very stateful and object-oriented. From jQuery to Ext.js, and the likes. Working with those was very problematic in many ways:
- State propagation was very error-prone, because you had to do it manually. (The framework only cared about giving you a zoo of components.)
- State was all over the place. Not as in “oh no, derived state here and there”, but as in “there is state in every little crevice of my SPA”. Debugging and refactoring that was hell (by modern standards).
- Some state was embedded into the DOM. (If you want a value of the checkbox component, you had to ask it by calling a method, and that would in turn ask the DOM. Ew.)
When React & Friends entered the industry, they streamlined the state management and decoupled the state from the DOM, making the aforementioned issues almost extinct.
In one part that was achieved with aggressive immutability: when framework detects a state change, it redraws the entire component tree. Such an approach can cause a colossal performance hit from all the relayout and repaint.
The concept of the Virtual DOM was introduced to solve that repaint issue. The framework will render everything into a pocket dimension, and then check the difference with the real DOM. The latter will be precisely hammered until it matches the Virtual DOM. But because the Virtual DOM is not inserted into document, it will not trigger any kind of visual recalculation.