5

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?

ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257
Ross Khanas
  • 1,491
  • 2
  • 15
  • 23
  • Please choose your tags carefully. This has absolutely nothing to do with [tag:git]. – ChrisGPT was on strike Jan 28 '15 at 18:03
  • Who said manual DOM manipulation would need to replace the divs? I'd just assign new values to the two text nodes if I'd care for speed. – Bergi Jan 28 '15 at 18:08
  • Bergi, this is just an example, we can have really deep tree with various DOM items, and we should be able to replace every part of our DOM tree. We can also have a lot of styles and classes appended to every DOM element. – Ross Khanas Jan 29 '15 at 00:44

2 Answers2

3

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.

the8472
  • 40,999
  • 5
  • 70
  • 122
  • Yes yes, when I do not interleave DOM manipulations I will have only 1 re-flow. But why do you think that virtual-dom is more relevant where we change full page? – Ross Khanas Jan 28 '15 at 23:17
  • 1
    The point is that you might get a whole HTML blob to replace the page because that's what is emitted by whatever is generating your UI. But even though it always emits the full HTML the changes themselves are only small and it's faster to not re-register all javascript widgets, repaint the whole page (only the changed parts instead) and not lose form inputs/caret position etc. In those situations it's useful. – the8472 Jan 29 '15 at 00:03
  • Yes, agree. That apparently means that I should design my app to use virtual-DOM just sometimes in some particular cases, not all the time. But it is probably possible to think about using it even with simple replacing some parts of DOM tree, but logic that creates a new virtual tree should be really fast. I will try to play with that. Thanks! – Ross Khanas Jan 29 '15 at 00:42
1

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.

Bohdan Kachmar
  • 33
  • 6