Why Are Node Operations Rarely Used in Frontend?

Because browsers have inherent defects in DOM manipulation. First of all, we need to know how the browser renders the code into a view after receiving the web page.

Different processes of a browser have different divisions of labor, among which the rendering process is responsible for rendering the page. ** Taking Chromium-based browsers as an example, the workflow is roughly like this:

• Parse HTML and construct DOM Tree
• Parsing CSS, constructing CSSOM
• Generate the final Render Tree from the comprehensive construction of DOM and CSSOM
• Calculate layout parameters for Render tree**
• The final Render tree, using the browser's rendering engine for drawing

It can be known that the process from HTML/CSS to Render Tree has gone through a very complicated process. Among them, the processes that take the longest time are the fourth and fifth steps: calculating layout parameters and drawing. When a DOM is added or removed from the page, the browser needs to start from scratch, construct the Render Tree, recalculate the layout and render the modified DOM tree again, which is a very resource-intensive and computationally intensive task.

The above is one reason, but there is another more important reason is that JavaScript accesses the information of DOM objects in the browser, and it also needs to build a bridge between JS and DOM, which needs to rely on the underlying implementation of the browser, which is also a very costly process. resource process. On the other hand, the resources of the main process are limited, and the JavaScript interpretation thread and rendering thread are mutually blocked. Manipulating the DOM requires JavaScript. Therefore, when JavaScript is executed, the view update will be blocked, and the rendering effect will be displayed externally, which will reduce the user experience.

Therefore, in order to reduce the adverse impact of manipulating the DOM on performance, there are two ideas:

• Reduce the number of visits to the DOM.
• Reduce the number of times to create and delete DOM objects, and reuse the existing DOM as much as possible.

For the first idea, the overhead of js accessing the DOM in the browser is very high, so you can use virtual DOM to solve this problem. Virtual DOM is a structure of simulated DOM that JS self-maintains. It stores the abstract information of real DOM, which can save the overhead of accessing real DOM. Changing the access to real DOM to virtual DOM, and changing the operation of real DOM to virtual DOM can reduce a lot of overhead.

For the second case, use the Diff algorithm to compare the information before and after the update on the virtual DOM. The Diff algorithm is essentially a tree traversal to find out the changed tree nodes. Therefore, after a bunch of operations on the virtual DOM, and then comparing the differences between the two trees before and after the operation, the original nodes can also be reused to a large extent to reduce overhead.

Take the Todo List as an example, use the <li> tag to store the item content. Now if you want to delete an item and add another item, then in the native method it is:

• Get the corresponding <li> element
• Remove the <li> element
• New <li> element
• Fill data and insert into current DOM tree, trigger Relayout and Repaint

But with Diff + Virtual DOM, it is:

• Store all <li> in a JS object in advance to construct a virtual DOM
• Remove <li> in virtual DOM
• Add <li> in the virtual DOM to get a new virtual DOM
• Using the Diff algorithm to compare the two new and old virtual DOMs, it is found that the number of DOMs has not changed, and the existing DOM objects can be reused, and there is no need to delete or create DOMs, just change the data.

Now front-end frameworks such as React\Vue use the Diff algorithm and virtual DOM to reduce the unnecessary performance overhead of operating and accessing DOM, roughly following the above ideas, and making up for the performance defects of front-end DOM operations.