4 ms·

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.

by mosdl 5y ago

hajile 5y ago
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 5y ago
  FxN was quite funny, must be a really bad framework that grows like that.
bayesian_horse 5y ago
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 5y ago
  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.

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.

by mosdl 5y ago

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 5y ago

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 5y ago
FxN was quite funny, must be a really bad framework that grows like that.

bayesian_horse 5y ago

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 5y ago
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.