Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

11–20 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#11
Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast. Definitely fast enough for 99% of all uses cases if not more. The benchmarks they all provide are just benchmarks. I treat them like I treat car range reports by the car makers. I personally use react because I know it well, and it allows me super speedy development cycle once all the base components are done. I'm sure another person will say "I use Svelte because A, B and C". etc.

Re: Virtual DOM is pure overhead (2018)

#13
post #5

Inferno.js uses VDOM https://github.com/infernojs/inferno and is faster than Svelte according to these benchmarks https://krausest.github.io/js-framework-benchmark/2023/table... . Sooo, VDOM can improve performance?

> Sooo, VDOM can improve performance?

This article doesn't really argue against that. They say the VDOM is a "means to an end" and is "generally good enough".

The thrust of the article seems to be that a virtual DOM isn't a guarantee of performance. Rather it's just one solution that can be pretty fast. Svelte happens to take a different approach which is also pretty fast.

Re: Virtual DOM is pure overhead (2018)

#15
post #11

Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast . Definitely fast enough for 99% of all uses cases if not more. The benchmarks they all provide are just benchmarks. I treat them like I treat car range reports by the car makers. I personally use react because I know it well, and it allows me super speedy development cycle once all the base…

I agree. Getting kind of sick of these posts that are thinly veiled political campaigns against the other framework. Great libraries tend to speak for themselves in terms of adoption. You shouldn't have to convince people not to use other options.

Re: Virtual DOM is pure overhead (2018)

#17
The key observation about HTML templates is that usually large portions of them don't change with new data. There is static content, and even with lots of dynamic bindings they're tied together in a static structure.

So the vdom approach of processing all the static parts of a template during a diff is just extremely wasteful, especially for fairly common cases like conditionally rendering a node before some static content.

Ideally you already know what changed, and can just update the parts of the template that depend on it. In JS that typically requires a compiler, complexity, and custom semantics (like Solid). But you can get very, very close to that ideal with plain JS syntax and semantics by capturing the static strings and the dynamic values separately then only comparing the dynamic values on updates.

This is what we do with lit-html and why I think tagged template literals are nearly perfect for HTML templates.

With tagged template literals, an expression like:

    html`Hello ${name}!`
is passed to the `html` tag function as an array of strings `['Hello ', '!']` and an array of values: `[name]`, and the strings array is the same every time you evaluate the expression, so you can compare it against the previous template and only update the values in the DOM if it's the same.

It's a really efficient way to render and update DOM with a pretty simple conceptual model that requires no compiler at all - it's all runtime. I think it's straightforward and powerful enough to be standardized at some point too.

Re: Virtual DOM is pure overhead (2018)

#20
Poorly written react code isn't performant and removing the Virtual DOM will not fix your problem. It's a hill I'm willing to die on. Many engineers seem to struggle with unnecessary re-renders, to the point where I see long tasks in the performance tab. Clicking a button shouldn't lock the UI thread for 2 seconds.
Post reply on HN