[thoman23]

2 things I'm not seeing in the article or in the comments so far:

1) The virtual DOM is an abstraction that allows rendering to multiple view implementations. The virtual DOM can be rendered to the browser, native phone UI, or to the desktop.

2) The virtual DOM can, and should, be built with immutable objects which enables very quick reference checks during the change detection cycle.

[spankalee]

There are other ways to represent a UI as data that don't require a diff. JSX's default compiler output throws away information needed to do efficient updates, and instead requires diffing the entire old and new trees.

Immutable objects may optimize for checking for data changes, but only if you do that, as in shouldComponentUpdate or checking inside render(). They don't optimize the _diff_, which is done against the DOM.

[keymone]

How often is diff done against the DOM? My understanding is that it’s done against last valid vDOM instead.

[spankalee]

Sorry, you're correct for React, and for most VDOMs, though some do diff against the DOM.

The point is that the diff isn't sped up by using immutable data. The app data is only used to generate the vdom tree, and the diff is after that.

[kgwxd]

On point #2, ClojureScript not only provides immutability out of the box, but also has libraries for replacing JSX with the same stuff everything else is built with. It's an insanely beautiful way to work with React.

[city41]

Reagent is probably the best UI dev experience I’ve found yet.

A quick blog post explaining why for anyone curious about reagent: https://www.mattgreer.org/articles/reagent-rocks/

[kgwxd]

There's a good discussion about this article on the Clojure Reddit sub: https://www.reddit.com/r/Clojure/comments/bqh0z4/virtual_dom...

[chrismorgan]

1: there’s no reason at all why VDOM should be the abstraction over the multiple view implementations; there’s no need: it’s all duck typed, so make DOM (or at least the subset of it that Svelte will generate) the abstraction that other things must implement. I believe this is how Svelte Native works.

Furthermore, as a compiler, Svelte is well placed to render to multiple implementations, efficiently—though implementing it is likely to take more effort if you’re dealing with a different-shaped API. This is demonstrated by the fact that Svelte has two compilation targets at present. First, dom, which is designed for client-side DOM operation; and secondly, ssr, server-side rendering, which is based on emitting strings, and never constructs a DOM.

2: even if you can do things that way, you’re still doing more work than is necessary, because you’re calling the whole render method and performing even simple comparisons that just aren’t necessary. VDOMs render methods are allocation-heavy, because they deliberately create new objects all over the place. In the words of the article, which I assert does deal with this, albeit obliquely: virtual DOM is pure overhead.