Hacker News Reader

Comment by seanwilson | Hacker News Reader

I'm guessing diffing and updating the DOM is really inefficient if there's a lot of DOM elements and a few frequently updating part of your UI?

e.g. if you added a clock to the game in the article that updates every few fractions of a section to show something like "14.3 seconds taken so far".

The solution to this would be to make the clock into its own tiny self-contained component and to make diffing smarter so that only the DOM parts that belong to the clock need to be diffed/checked each clock update?

View on HN

You would think that diffing is inefficient, but apparently modifying the DOM is significantly more inefficient. Mithril -- the framework that inspired this example -- has an interesting take: https://mithril.js.org/vnodes.html

I think he means that this snippet of code doesn’t account for diffing like React does and would fail if scaled out. I think the OP is aware of that though.

As a 33 line implementation "just for fun" exercise, no need to guess: this was not meant to be actual React in fewer lines of code =)

I don't know how React does it so it was a genuine question. I'm assuming they do some smart diffing to be more efficient.

It'll be irrelevant for most apps but I'm curious how much less efficient all this is compared to (in CPU time, not developer time) updating the DOM directly e.g with:

      document.querySelector('.timer').textContent = "5 seconds"

Mithril's approach (as robertakarobin refers to) is that diffing VDOMs is cheap (where as updating the DOM itself is expensive), the "library" in this post takes the same approach.

It's interesting, there's a lot of chat about performance with these frameworks, yet I'm not sure how much is relevant to the real world. When I do eg a

  document.querySelectorAll('*')

on airbnb map view (I guess a pretty good example of a mid complexity SPA), there are 3407 DOM elements - doing a diff on the VDOM elements of these should quick.

If I were doing something like a clock on a page (or an animation for example), I'd probably just do it out-of-band of my framework. These kind of things tend to be few and far between anyways.

That's why I prefer the Svelte way of doing things. It compiles down to code that directly changes the DOM, but only the parts that need to be updated.

Do you know where to find docs on what svelte actually compiles to? I’m curious how they store/reference/update dom nodes in the compiler output.

This[0] (2-part blog entry) is a good write-up of what's going on, by a svelte contributor.

Also, as suggested by the author, taking the tutorial[1] is useful (and the repl generally) to see what's going on. In the repl, look at the "JS output" tab. Play around with it to see what the compiler outputs.

[0] https://lihautan.com/compile-svelte-in-your-head-part-1/

[1] https://svelte.dev/tutorial/basics

Another good one

https://lihautan.com/the-svelte-compiler-handbook/

Reply on news.ycombinator.com