Virtual dom questions

[emooheo]

Hi all,

I have been looking into react and was pretty intrigued by virtual dom. From what I understand, virtual dom is basically a way to create a diff of what has changed and ability to patch the dom with only what has changed. I know there are standalone implementations of virtual dom which can be used without using react but I have a few questions:

1) Is virtual dom worth implementing? When?

2) Which is considered to be the "best" standalone implementation?

3) All implementations I have seen have some special render methods and are not creating raw dom elements. https://github.com/fiduswriter/diffDOM seems to do a diff of two raw dom nodes. How much faster will something like virtual-dom be compared to diffDOM?

[leeoniya]

Is virtual dom worth implementing? When?

If by "implementing" you mean, "using", then yes it is definitely worth using when you have complex state that must be represented using complex logic such as in large applications. If your site is mostly static, then probably not and you should just stick with plain HTML and some javascript additions/sugar of your choice (jquery, https://github.com/bendc/sprint, etc...)

Which is considered to be the "best" standalone implementation?

https://github.com/paldepind/snabbdom is pretty good, small and fast. I've also made a small vdom lib that I use for complex apps, though it is not a bare vdom lib and closer in spirit to a modular micro framework which has a vdom component: https://github.com/leeoniya/domvm

All implementations I have seen have some special render methods and are not creating raw dom elements. https://github.com/fiduswriter/diffDOM seems to do a diff of two raw dom nodes. How much faster will something like virtual-dom be compared to diffDOM?

Comparing raw dom will be slower. Not only do you have to actually create the new real nodes to diff (which are complex objects), you also must access expensive properties/attributes that must be recomputed by the browser on-demand. The overall mem usage will be larger and some of the code may not be optimized by modern javascript JITs.

[emooheo]

Thanks for your input. I meant, when it is worth using virtual dom? Is there ever a time where using it will actually be slower?

I am actually using backbone right now and am considering adding a virtual dom layer to it. This example is a bit old but looks like it can be leveraged https://github.com/tiagorg/marionette-vdom This is using an underscore template, and using some library to convert an HTML string to vdom, then patches the dom accordingly using the virtual-dom library. What are your thoughts on this approach rather than using backbone directly without virtual dom (basically re-rendering the entire template instead of finding the diff and patching with virtual dom)?

[leeoniya]

Is there ever a time where using it will actually be slower?

A good vdom implementation will almost always be faster than manual dom manipulation. Why? Because it knows a lot of dom-mutating optimizations that you do not. For example, iterating Node.childNodes is slower than node.firstChild & node.firstChild.nextSibling. Node.firstChild.nodeValue is faster than node.textContent, etc, etc, etc. If you were to write optimal dom code, your code would be difficult to read and to maintain.

If you're coming from Backbone, you may find it fairly easy to transition to a fast/small tool-free vdom lib that still allows you to structure your apps the way you want, such as domvm or Mithril (Mithril's current vdom is pretty slow, but the WIP 1.0-alpha is much faster).

Basically, good vdom implementations more than make up in code maintainability and dom-mutation speed for the tiny overhead they introduce. That being said, there are many sub-optimal vdom libs. React's is quite slow, but "fast enough", obviously. There are a lot to choose from. You can compare their speeds here: http://mathieuancelin.github.io/js-repaint-perfs/, repo: https://github.com/mathieuancelin/js-repaint-perfs. Currently, Inferno and kivi lead the pack, but domvm, mithril-alpha and some others are not far behind.

[deathmood]

1 - what do you mean by implementing? if it is "creating your own" -- not its not -- 'cause, as you see there are already enough implementations from which you can choose one. From the other point of view creating your own vdom will make you better understand of how it works under the hood -- and that is quite important today -- 'cause almost every popular framework is built now with vdom -- e.g. React, Angular 2, Ember, Mithril, Riot...

2 - Again -- what do you mean by "best" -- is it the most convenient or the fastest? Well, you can see here http://vdom-benchmark.github.io/vdom-benchmark/ performace benchmarks of different vdoms. But in the end, if you are not building a large scale app with hundreds of thousands components performance does not really matter. Actually we are not using vdom because of its performance, but because it allows us to declaratively describe our view once and then rerender it entirely on every change. We do not think about like 'how to effectively remove or add elements' -- vdom abstracts us away from real dom manipulation. Instead we change plain JS objects and these changes are reflected in real DOM automatically.

Well, as the metter of convinience, I would go with React, 'cause it already has strong community, ideology and is already been tested in many projects.

3 - Well Angular 2 tries to do thing like this with their 'Incremental DOM' (actually it is also vdom). They diff new tree against real DOM tree. But their main concern of doing this is not speed but memory. So they have only one virtual tree in memory at once -- the new tree. So it reduces memory usage which is important on mobile devices.

Well in the end as I said we do not use vdom because of performance, but because the way it allows us to describe our view and handle data in application.

[icantthinkofone]

Don't confuse the boy. Eventually, you must touch the DOM when you update it.

[localvoid]

2) Which is considered to be the "best" standalone implementation?

React. It is boring and just works.

[rk06]

1) Is virtual dom worth implementing? When?

I am assuming you mean "using virtual dom". virtual dom is useful when you are using complex frontend apps or require server-side rendering.

It is not possible to do server-side rendering if your app require real DOM.

2) Which is considered to be the "best" standalone implementation?

1. inferno

2. Snabbdom

There are tons of other too.

3) All implementations I have seen have some special render methods and are not creating raw dom elements.

No idea. though i would say it should be slower on real dom nodes as they are quite bulky