VDOM is cheaper than a
naïve DOM approach, but a lot more expensive than an
efficient DOM approach.
Let’s use as our context TodoMVC (http://todomvc.com/), and the action of adding a new item to the list, after having typed something in the box and pressed Enter.
The most efficient solution to adding an item is to craft a single new and insert it in the right place into the list.
One extremely inefficient DOM approach would be to replace the entire list in the DOM, iterating through all the items and making a new for all of them. This will work OK for a very few items, but once you get lots of items, it makes adding items very slow, because the browser is having to throw away a large number of DOM elements and insert a new bunch of DOM elements, applying their styles and all.
The VDOM approach is to have a virtual DOM that can be comparatively cheaply crafted, and rerender the entire list, but using that VDOM rather than the actual slow DOM; then, compare the old rendering and the new rendering, and apply any changes to the DOM—in this case, that will mean that it does finally craft that single new , inserting it in the right place.
The VDOM approach is inherently doing more work than is strictly necessary; but it does so and has become popular in recent years because it makes it decidedly easier to write that code, and makes it harder to make mistakes, because you’re only defining how to render a view, rather than how to render a view as well as how to synchronise changes in the data.
So long as you’re sensible in what you do, Overture is much faster than anything that uses a VDOM. But you’re responsible for hooking things up so that it knows that, when such-and-such a property changes, it needs to be redrawn in such-and-such a fashion. That can be hooked up in many ways; the most blunt is to say “when any property changes, redraw the entire view,” and the most fine is to say “in a todo item view, when the text of the item changes, replace the contents of its text node (which we stored a reference to when we drew it in the first place)”—and you’re not going to get more efficient than that! But as you can imagine, there’s a lot more scope for making mistakes which lead the view being out of sync with the data.
It’s all about tradeoffs. The VDOM approach lets you develop things faster, while the efficient DOM approach produces a result that runs faster and more smoothly. There are good arguments to be made in both directions; but I’m glad that we at FastMail focus on making it fast for the user.
The Ember team’s work with Glimmer is an impressive hybrid of the two models; the Why Tracked Properties? section of https://glimmerjs.com/guides/tracked-properties is a really good summary of some of the issues around VDOMs, and how Glimmer engineers around them. I like Glimmer.