A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

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


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.


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


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.


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.


Have a look at this library:

A Fast & Light Virtual DOM Alternative

Polymer plays with this approach