When virtual-dom is faster than manual manipulation?

Question

I'm investigating virtual-dom right now, and I'm wondering whether virtual-dom is really faster than manual manipulation with view. Now I understand that virtual-dom and diff algorithm can prevent unnecessary re-flows, for example when we want to change this:

<div>
    <div>a</div>
    <div>b</div>
</div>

To this one:

<div>
    <div>c</div>
    <div>d</div>
</div>

So when we use direct manipulation we will have probably 4 re-flows: 2 for removing each div and for creating new one. We will also have more manipulation with dom, because we should create new elements (Maybe removing from dom -> creating new dom -> setting properties -> mounting to document is faster then just direct editing dom properties?). From the other side we have fast pretty diff algorithm that generate 2 patches just to replace content of our divs, probably we will have 1 re-flow. (if I made a mistake while writing number of re-flows, please tell me)

In this case virtual-dom probably rules, but when we have 2 really different trees, we will not have a lot of benefits from diff, so we will prevent some re-flows, maybe, but time for generating new tree and running diff and patch is much longer. And here is my second question. For example, in the motivation to https://github.com/Matt-Esch/virtual-dom library, they say: "So instead of updating the DOM when your application state changes, you simply create a virtual tree or VTree". Is it really nice to build a new virtual tree every time when I need to change something on my view?

Of course, I will try to make some test to evaluate the performance, but I want to know some more technical aspects and reasons why virtual-dom is really better or, maybe, not?

Answer 1

So when we use direct manipulation we will have probably 4 re-flows: 2 for removing each div and for creating new one.

If you batch your DOM manipulation operations and do not interleave them with operations that need to read the layout state (e.g. reading computed styles, calculating offsets) then all those manipulations taken together will only cause a single reflow.

The reflow and repaint algorithms of browsers are also fairly advanced these days, only adjusting parts of the document and simply re-compositing the moved layers without repainting them if they don't change their dimensions.

If you are concerned about performance you should use the performance profiling tools of your browser and see what is actually slowing you down and whether it can be optimized with native utilities before making premature optimizations.

I think virtual dom is more meant for situations where something (e.g. the server) emits a full page DOM tree but you only want to apply the differences.

Answer 2

When you use virtual-DOM you also take some responsibility from user to think about the reflows.

When you apply patches you apply them together without reading DOM state. This moment can help you to avoid unnecessary reflows.