What is the virtual DOM

Explanation 1: Use JS to simulate a DOM tree and store it in the browser’s memory. When changes are needed, the virtual DOM performs diff algorithm to compare the old and new virtual DOM and puts the changes into a queue. To the actual DOM, reduce DOM manipulation.

Explanation 2: The virtual DOM transforms the DOM into a JS tree. Diff algorithm step by step to compare, delete, add operations. However, if multiple elements are the same, performance may be wasted, so React and Vue reference key values to distinguish between them.

Why is DOM rendering slow?

DOM rendering is the process by which the browser converts an HTML string into a web page view and renders the view.

  1. First, the browser’s HTML parser parses the HTML string and converts it into a DOM tree. At the same time, the CSS parser also parses the CSS styles used by the HTML and generates a series of CSS rules.
  2. The browser’s rendering engine then integrates the DOM tree with the CSS rules and generates a DOM rendering tree that can be used to render the view.
  3. You then determine the DOM layout, the exact location of each node in the browser.
  4. The final step is to draw, drawing every pixel of each node on the screen.

To understand the complexity of this process, we can take a close look at the processing of an HTML parser. In an HTML parser, two programs are executed alternately: a word parser and a parser; The word splitter is responsible for dividing the HTML string into legal DOM tag strings and then handing them to a parser for processing, which adds them to the DOM tree being built; The DOM tree is built when the toener parses all strings.

You can understand why DOM rendering is so slow: the process is really complicated. Adding and removing DOM from Web page interactions greatly reduces the efficiency of view rendering and interaction.

Why do we use the virtual DOM?

  • Guaranteed performance lower limit
  • I can still give you decent performance without the need for manual optimization
  • cross-platform

Four, ensure the performance offline

The framework’s virtual DOM needs to accommodate any operations that the upper-level API might produce, and some of its DOM operations must be implemented in a universal way, so its performance is not optimal; But performance is much better than rough DOM manipulation, so the framework’s virtual DOM can at least guarantee decent performance without having to manually optimize it.

For example, compare the redraw performance cost of innerHTML vs. Virtual DOM:

  • InnerHTML: render HTML string O(template size) + create all DOM elements O(DOM size)
  • Render Virtual DOM + diff O(Template size) + necessary DOM update O(DOM change)

Virtual DOM Render + diff is obviously slower than rendering HTML strings, but! It’s still pure JS level computation, and it’s still a lot cheaper than the DOM manipulation that follows.

As you can see, the total amount of innerHTML computation — both the JS calculation and the DOM operation — is related to the size of the entire interface. However, in the Virtual DOM, only the JS calculation is related to the size of the interface, while the DOM operation is related to the amount of change in the data.

As mentioned earlier, JS computation is extremely cheap compared to DOM manipulation. That’s why there’s a Virtual DOM: It guarantees acceptable performance every time you redraw, no matter how much your data changes. Ensures performance offline.

5. I can still give you decent performance without manual optimization

Here is a direct look at you dada in zhihu’s explanation.

Vi. Cross-platform

The virtual DOM is essentially a JavaScript object, and the DOM is platform-dependent, making it easier to operate across platforms, such as server rendering, WEEX development, and so on.

React is faster than React.