Direct manipulations of DOM are expensive. It is vastly more cheaper to create or update JS object than create or manipulate DOM node. So the claim that VirtualDom is always an overhead is not true. The diff algorithm can give a set of DOM operations that are less expensive than typical sequence of manual mutations. So virtual DOM can be faster if savings from less DOM operations are bigger than extra JS work.
Surely carefully crafted direct DOM mutations will be the fastest approach, but it typically leads to hard to maintain code.
I'm not sure you understood the article. The Svelte compiler does in fact generate code that performs "carefully crafted direct DOM mutations," though it is not hard to maintain, because the compiler handles it. Given code that already knows exactly which DOM updates to make, virtual DOM would indeed be pure overhead.
Typical React code does not know which updates to make. It always builds the Virtual DOM from scratch as is was the first time. It is the diff algorithm then figures out the set of changes.
If code knows which updates to make, it essentially embeds a particular form of the diff algorithm. That inevitably leads to more code to write as besides the initial construction of DOM one has to track changes. And such manual tracking is not necessary optimal as the diff algorithm has a global picture and can target the globally optimally set of mutations, while manual in-component tracking optimizes for a particular component.
> If code knows which updates to make, it essentially embeds a particular form of the diff algorithm.
Having an alternative means of identifying where to make targeted updates on data changes (i.e., via static analysis during a compilation step) is not the same thing as embedding "a particular form of the diff algorithm" (which would be a runtime operation). Svelte does not produce anything comparable to a diff algorithm.
> That inevitably leads to more code to write as besides the initial construction of DOM one has to track changes.
With Svelte, there is actually less code to write, as the compiler handles generation of the change tracking code. And even the generated code is minimal and generally leads to much smaller bundles, as no runtime gets shipped with the code. This leads to faster startup times, which is often the real performance bottleneck for SPAs.
> And such manual tracking is not necessary optimal as the diff algorithm has a global picture and can target the globally optimally set of mutations, while manual in-component tracking optimizes for a particular component.
Can you offer an example where a "globally optimal set of mutations" would be different from the set of mutations Svelte would make on a given change?
the author and others did not avocate manual DOM manipulations. He wrote a framework that can generate optimal DOM manipulation code without the need of a virtual DOM.
Surely carefully crafted direct DOM mutations will be the fastest approach, but it typically leads to hard to maintain code.