4

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.

devdevdove
  • 147
  • 1
  • 3
  • [This page](https://www.codecademy.com/article/react-virtual-dom) explains it well. React does a *diff* between the virtual DOM and the real one, and only updates the elements in the real DOM that have changed. – Robert Harvey Oct 20 '22 at 19:13
  • AFAICT, it's essentially a double-buffering solution. I've read well-reasoned claims that it is totally unnecessary. – JimmyJames Oct 20 '22 at 20:42
  • "Virtual DOM" is just a data structure held in memory that's a framework-specific and browser-independent representation of the real DOM (or, you can think of it as a representation of the UI of the application - a tree of controls + maybe some metadata). It's not necessarily simple, but it also doesn't have to strictly adhere to the DOM Standard, and is disconnected from rendering. The real DOM is a browser-specific impl. of the standard, a tree of objects; there are some differences between browsers. Virtual DOM allows them to do a diff, and then only update corresponding stuff in real DOM. – Filip Milovanović Oct 20 '22 at 21:35
  • "Why does DOM not do that itself?" - cause it doesn't know that anything changed; you're not updating the page content (the real DOM), you're updating the virtual DOM (again, a separate in-memory data structure), and then React figures out what's updated, and males the real DOM reflect that. There's a cycle: some logic happens, React manipulates its internal data structures and constructs the virtual DOM, does a diff with a previous snapshot of the virtDOM, and then has a phase where it updates the real DOM. This happens over and over. See: https://geekflare.com/react-rendering/ – Filip Milovanović Oct 20 '22 at 21:35
  • BTW, the real DOM is just your elements in the document. The browser updates its display immediately when you change something. E.g., hit F12 (or Ctrl+Shift+I) to open the dev tools, and type this in the console: `var headerDomElement = document.getElementById("question-header")`. That's one DOM element from this page. Now if you do `headerDomElement.style.backgroundColor = "cyan"` , you'll see that the header background color will update as soon as you execute that. React ultimately does the same thing - it's just JavaScript - but does it in a more structured way, with a lot of bookkeeping. – Filip Milovanović Oct 20 '22 at 21:55
  • If it helps: the general idea is that the real DOM isn't designed to be fast because why would you need it to be. – user253751 Oct 21 '22 at 17:14

1 Answers1

2

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.

Shadows In Rain
  • 669
  • 5
  • 13