Why is vdom/diffing a necessary requirement for JavaScript frameworks? Is there a better long term solution?


#1

So many JS frameworks utilize a vdom/diffing technique. I know very little about how it actually works, other than the goal of minimizing repaints. It doesn’t feel right. Has there been a discussion regarding a better long term solution?

For example, you could buffer (delay/queue) DOM changes: document.buffer(). All DOM operations are then delayed until they are flushed? Couldn’t the browser do most of this automatically?

I suppose it’s the requirement that when you “addClass()”, then traditionally you’d expect the DOM/layout to reflect the change immediately, on the next line of code. So it is a bit of a paradigm shift.

Behind the scenes, it might be something similar to vdom/diffing. But instead of building it with JavaScript, it would be baked into the system. That seems like a better long term solution.

Alternatively, I’ve wondered if you could use a DOM placeholder:

  1. Replace a DOM node with a dummy clone (temporary placeholder that lasts a matter of milliseconds)
  2. Make all operations on the original DOM, that is now in-memory, removed from the document, and does not trigger repaints
  3. When you’re done, swap them back

In fact, maybe using a placeholder (the clone and swap operations) just slows it down, and you might be able to remove/replace the dom fast enough that the user doesn’t notice? This might be risky if the process slows down too much, and you can see a flicker.

Anyway, by removing the DOM, you can do direct manipulations without worrying about jank.


#2

We built an entire game development IDE in the browser. We don’t use any VDOM or diffing. DOM call overhead is not a significant problem. Layout performance is a far bigger problem. I wrote about this in more detail here: https://www.scirra.com/blog/ashley/35/layout-is-the-next-frontier-of-web-app-performance


#3

There’s other techniques, for example mapping object changes directly to DOM mutation rather than diffing (off top of my head I know Aurelia and Turbine do this, without diffing). I’ve compiled a fairly exhaustive list of view-layer alternatives, but that was a while back. There may be even more of them now.


#4

Apple’s recent proposal for standard template instantiation and updating does not use a virtual-DOM method. It is being discussed in the template-tagged GitHub issues of the Web Components’ GitHub repository.


#5

Have a look at this library:

A Fast & Light Virtual DOM Alternative

Polymer plays with this approach