4 ms·

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 add

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?

robertakarobin 7y ago
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 https://mithril.js.org/vnodes.html
- websitescenes 7y ago
  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.
  - TheRealPomax 7y ago
    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 =)
  - seanwilson 7y ago
    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"
leontrolski 7y ago
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.
learc83 7y ago
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.
- jsf01 7y ago
  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.
  - PKop 7y ago
    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/ https://lihautan.com/compile-svelte-in-your-head-part-1/ [1] https://svelte.dev/tutorial/basics https://svelte.dev/tutorial/basics
    - PKop 7y ago
      Another good one https://lihautan.com/the-svelte-compiler-handbook/ https://lihautan.com/the-svelte-compiler-handbook/

robertakarobin 7y ago

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 https://mithril.js.org/vnodes.html

websitescenes 7y ago
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.
- TheRealPomax 7y ago
  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 =)
- seanwilson 7y ago
  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"

leontrolski 7y ago

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.

learc83 7y ago

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.

jsf01 7y ago
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.
- PKop 7y ago
  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/ https://lihautan.com/compile-svelte-in-your-head-part-1/ [1] https://svelte.dev/tutorial/basics https://svelte.dev/tutorial/basics
  - PKop 7y ago
    Another good one https://lihautan.com/the-svelte-compiler-handbook/ https://lihautan.com/the-svelte-compiler-handbook/