4 ms·

> ... expensive VDOM diffs Wait, I thought VDOMs were supposed to be fast(er). Note: I'm not a FE Dev, so I'm only going by stuff I (think I) read, not write.

abiox 8y ago
fast(er) is relative. and _not_ doing a thing is often faster than doing a thing.
- gldalmaso 8y ago
  Isn't vdom diff a way to not do things?
  - spankalee 8y ago
    You have to do the diff, which is a thing. lit-html doesn't do the diff because it knows from the template what parts actually change. No need to diff the parts that never change.
- eropple 8y ago
  Replacing the entire tree is very rarely, if ever, faster than doing the fast thing.
  - rictic 8y ago
    True, but neither virtual-dom nor lit-html replace the entire tree.
- iteriteratedone 8y ago
  Faster: general notuon of speed ... we are splitting hairs Not needed for 99.9% of features
acdha 8y ago
It ultimately comes down to Amdahl's law: doing something in a browser requires updating the DOM. Since you always have to do the DOM processing, the only way adding the extra virtual DOM work will be a net win is if it makes it easier to avoid unnecessary updates or allows something like ordering updates to avoid triggering repeated layouts / reflows[1]. Since updating the DOM is relatively fast in modern browsers it's not particularly hard to find cases where the work the virtual DOM has to do cancels out any savings. 1. See e.g. https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing https://developers.google.com/web/fundamentals/performance/r..., a list of triggers at https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a, and https://github.com/wilsonpage/fastdom https://github.com/wilsonpage/fastdom for a common technique to avoid it by manually ordering read operations before writes.
chrismorgan 8y ago
Here’s a moderately detailed explanation I made a few months ago: https://news.ycombinator.com/item?id=15957517 https://news.ycombinator.com/item?id=15957517.

abiox 8y ago

fast(er) is relative. and _not_ doing a thing is often faster than doing a thing.

gldalmaso 8y ago
Isn't vdom diff a way to not do things?
- spankalee 8y ago
  You have to do the diff, which is a thing. lit-html doesn't do the diff because it knows from the template what parts actually change. No need to diff the parts that never change.
eropple 8y ago
Replacing the entire tree is very rarely, if ever, faster than doing the fast thing.
- rictic 8y ago
  True, but neither virtual-dom nor lit-html replace the entire tree.
iteriteratedone 8y ago
Faster: general notuon of speed ... we are splitting hairs Not needed for 99.9% of features

acdha 8y ago

It ultimately comes down to Amdahl's law: doing something in a browser requires updating the DOM. Since you always have to do the DOM processing, the only way adding the extra virtual DOM work will be a net win is if it makes it easier to avoid unnecessary updates or allows something like ordering updates to avoid triggering repeated layouts / reflows[1]. Since updating the DOM is relatively fast in modern browsers it's not particularly hard to find cases where the work the virtual DOM has to do cancels out any savings. 1. See e.g. https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing https://developers.google.com/web/fundamentals/performance/r..., a list of triggers at https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a, and https://github.com/wilsonpage/fastdom https://github.com/wilsonpage/fastdom for a common technique to avoid it by manually ordering read operations before writes.

chrismorgan 8y ago

Here’s a moderately detailed explanation I made a few months ago: https://news.ycombinator.com/item?id=15957517 https://news.ycombinator.com/item?id=15957517.