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.
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.
A quick blog post explaining why for anyone curious about reagent: https://www.mattgreer.org/articles/reagent-rocks/
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.
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.