Why do we need to use a vDOM to gain performance? Why aren't efforts being made to make DOM itself fast? Is the DOM really slow enough to justify the extra dependency of a vDOM?
I know very little about the DOM so please take this with a grain of salt. Perhaps someone can correct anything wrong I say:
Changing values/adding nodes/removing nodes in a DOM isn't the expensive bit.
The expensive part is what happens after something changes in the DOM.
When a node is changed it triggers an invalidation of the current screen. The modified DOM means that something different should be on the screen compared to last render.
Naively this means that we recalculate the position and size of each node according to rules (CSS and otherwise) of the node, the node's parent and the node's children.
Now imagine we have 1 root node with 5 children nodes. Each of those children nodes have 5 nodes and those children have 2 nodes. Each node is display:block
Now a script is run. The first leaf node has the height property changed.
Now you have to recalculate the size and position of each node in that tree.
Okay that's fine but wait, the script continues to run. It's also increasing the height of the second leaf node. Recalculate the height of all the nodes again.
It turns out that the script was a for loop and it's increasing the height of all the leaf nodes.
So you've just remeasured the DOM 50 times when you could have remeasured once by using a virtual DOM.
To reiterate I know nothing about the DOM so I'd appreciate someone else clarifying and correcting my comment.
This is pretty much the root of it, it's not so much the DOM as it is the dependencies involved in layout, paint, and compositing.
Anything that might re-trigger layout in particular will have a noticeable impact on complex sites. That can be adding or removing nodes or just adjusting some CSS rule or adding/removing a class.
There is a lot of work being done recently to allow browsers to distinguish exactly which CSS rules can cause relayout, and which nodes can be changed in which ways without affecting other nodes. There's also work to better separate out exactly which stages depend on which pieces so that more work can be done in parallel and more work can be re-used (don't need to re-render this sub-tree X if we know for certain that a change over here in Y can't possibly affect it, that kind of thing).
Mozilla Servo/WebRender is probably the most interesting project right now if you want to dig deeper.
5 comments
[ 5.3 ms ] story [ 19.0 ms ] threadChanging values/adding nodes/removing nodes in a DOM isn't the expensive bit.
The expensive part is what happens after something changes in the DOM.
When a node is changed it triggers an invalidation of the current screen. The modified DOM means that something different should be on the screen compared to last render.
Naively this means that we recalculate the position and size of each node according to rules (CSS and otherwise) of the node, the node's parent and the node's children.
Now imagine we have 1 root node with 5 children nodes. Each of those children nodes have 5 nodes and those children have 2 nodes. Each node is display:block
Now a script is run. The first leaf node has the height property changed.
Now you have to recalculate the size and position of each node in that tree.
Okay that's fine but wait, the script continues to run. It's also increasing the height of the second leaf node. Recalculate the height of all the nodes again.
It turns out that the script was a for loop and it's increasing the height of all the leaf nodes.
So you've just remeasured the DOM 50 times when you could have remeasured once by using a virtual DOM.
To reiterate I know nothing about the DOM so I'd appreciate someone else clarifying and correcting my comment.
Anything that might re-trigger layout in particular will have a noticeable impact on complex sites. That can be adding or removing nodes or just adjusting some CSS rule or adding/removing a class.
There is a lot of work being done recently to allow browsers to distinguish exactly which CSS rules can cause relayout, and which nodes can be changed in which ways without affecting other nodes. There's also work to better separate out exactly which stages depend on which pieces so that more work can be done in parallel and more work can be re-used (don't need to re-render this sub-tree X if we know for certain that a change over here in Y can't possibly affect it, that kind of thing).
Mozilla Servo/WebRender is probably the most interesting project right now if you want to dig deeper.