The actual DOM and its parsing process?
The browser rendering engine workflow is similar, roughly divided into 5 steps: create a DOM tree — create StyleRules — create a Render tree — Layout — paint
The first step is to use an HTML parser to analyze HTML elements and build a DOM tree (tokenization and tree construction).
The second step is to use a CSS parser to analyze inline styles on CSS files and elements and generate a style sheet for the page.
The third step is to build a Render tree (also known as an Attachment) by associating the DOM tree with the stylesheet. Each DOM node has a attach method that takes style information and returns a Render object (aka renderer). These render objects will eventually be built into a Render tree.
Step 4, with the Render tree, the browser starts laying out the layout and determines the exact coordinates for each node in the Render tree to appear on the display.
Step 5, with the Render tree and node display coordinates in place, call the paint method for each node and draw them.
The DOM tree is built when the document is loaded, right? Building the DOM count is a gradual process, with the rendering engine bringing the content to the screen as soon as possible for a better user experience. It doesn’t have to wait until the entire HTML document has been parsed to start building render numbers and layouts.
Was the Render tree built after the DOM and CSSOM trees were built? In practice, these three processes are not completely independent, but cross. Will cause a load, a parsing, a rendering work phenomenon.
CSS parsing is done from right to left (bottom-top parsing is more efficient than bottom-bottom parsing in the DOM tree). The more nested tags, the slower parsing is.
Second, the cost of JS operating the real DOM!
In our traditional development model, when native JS or JQ manipulates the DOM, the browser executes the process from start to finish, starting with building the DOM tree. In one operation, I needed to update 10 DOM nodes, and the browser received the first DOM request and didn’t know there were nine more updates, so it immediately executed the process and ended up doing 10. For example, after the first calculation, the next DOM update request, the coordinate value of this node changes and the previous calculation is null. Calculating the coordinate values of DOM nodes is a waste of performance. Even though computer hardware is constantly updated, DOM manipulation is still expensive, and frequent manipulation still leads to page stuttering and user experience.
Why is the virtual DOM needed and what are its benefits?
Virtual DOM, a common JS object to describe the DOM structure, because it is not a real DOM, so it is called the virtual DOM. Web interfaces are built from DOM trees (trees stand for data structures), and when one part of them changes, it actually changes for a DOM node. The virtual DOM was designed to address browser performance issues. For example, if there are 10 DOM updates in one operation, the virtual DOM will not immediately manipulate the DOM, but save the diff content of the 10 updates to a local JS object, and finally attch the JS object to the DOM tree for subsequent operations to avoid a lot of unnecessary calculation. Therefore, the advantage of using JS object to simulate DOM node is that the update of the page can be reflected in THE JS object (virtual DOM), and the speed of the JS object operation in memory is obviously faster. After the completion of the update, the final JS object is mapped into the real DOM and submitted to the browser to draw.