[bayesian_horse]

Virtual DOM overhead is totally overstated. It's just that it offends some people's idea of efficiency to build a data structure to throw most of it away anyway.

But in reality, the virtual DOM allows you to avoid manipulating the actual DOM, which is both slow and error-prone. The browser necessarily attaches all sorts of memory objects and state to components in the DOM, which his why unnecessary mutating has to be avoided at almost all cost.

Svelte may go a step further by automating DOM manipulation. But it doesn't have the same following yet. And usually, if there is no explosive growth in such a technology, it's not just because of evil overlords preventing its justful rise...

[mosdl]

You do know the vdom eventually has to change the DOM right? In the end the vdom always will have to do more work than regular dom manipulations.

[hajile]

vdom has the potential to do optimizations that simply aren't possible in individual functions because it sees the whole DOM at one time.

There's also the preact method which diffs against the DOM directly, so that overhead goes away.

Do you remember when InfernoJS broke the framework test? It blew away 2-3 versions of vanillaJS with it's vdom implementation. They literally tore apart what it was doing in order to finally create a vanilla version that was faster, but very unmaintainable.

Today, "native" frameworks like Svelte are only fractionally faster at synthetics. At the same time, each component contains a brand new set of functions which has two major drawbacks. First, code size grows at F x N (where F is framework size and N is your normal code) rather than F + N. Linked to this is the performance implications. Once the JIT warms up the vDOM code (almost instantly), the user gets max performance for the most critical loops when visiting pages for the first time. With "native" frameworks, each new page means switching back to completely unoptimized code.

[mosdl]

FxN was quite funny, must be a really bad framework that grows like that.

[bayesian_horse]

It is theoretically the case, that a virtual DOM implementation has to do more work than a perfectly efficient manual (or automatically generated) DOM mutation.

However, in practice the difference hardly matters and it is really hard to do efficient DOM mutation correctly. Which is why virtual DOM approaches are at the heart of most of the modern frameworks...

[mosdl]

They are at the heart because it allows people to write code faster while being OK with the perf/mem hit. But in the end its always less efficient which is why you have to hand wave it away.