4 ms·

How does M3 stand with SvelteJS? Seems like these are two conceptually similar things. > React traverses the virtual DOM tree to update the UI, resulting in O

How does M3 stand with SvelteJS? Seems like these are two conceptually similar things. > React traverses the virtual DOM tree to update the UI, resulting in O(n) time complexity. That's the worst case, on initial load. On most of UI changes nothing stops React to update only local portions of the tree - elements that have their state changed. Educated guess: In Million and React.JS cases major bottleneck is inside browser re-layout mechanism, not on JS side I think.

acdha 3y ago
> On most of UI changes nothing stops React to update only local portions of the tree - elements that have their state changed. In practice, it still re-renders a lot. It’s easy to get a significant performance increase by not using React (usually at least one order of magnitude) - browsers have improved a lot and what looked like an optimization for IE6 is largely overhead now.
- c-smile 3y ago
  > In practice, it still re-renders a lot. Neither framework will fix programmer's errors. This for(let child of container) child.innerHTML = getHtmlFor(i++); will always be slower than this: for(let i = 0; i < N; ++i) html += getHtmlFor(i++); container.innerHTML = html; N transactions versus 1 transaction. I mean that compiling separate N "small" DOM access calls is not always faster than one integral update.
  - acdha 3y ago
    My point was that that is enormously slower than storing a reference to the elements when you create them and setting only the specific attributes which changed. innerHtml string parsing forces the browser to do too much work unless you’re literally changing everything. Each time I’ve replaced that with DOM operations it’s been an order of magnitude or more performance gain - on one project, getting rid of fully-optimized React was 4 orders, but I think they’ve optimized it enough since then that it’s only 1-2.

acdha 3y ago

> On most of UI changes nothing stops React to update only local portions of the tree - elements that have their state changed. In practice, it still re-renders a lot. It’s easy to get a significant performance increase by not using React (usually at least one order of magnitude) - browsers have improved a lot and what looked like an optimization for IE6 is largely overhead now.

c-smile 3y ago
> In practice, it still re-renders a lot. Neither framework will fix programmer's errors. This for(let child of container) child.innerHTML = getHtmlFor(i++); will always be slower than this: for(let i = 0; i < N; ++i) html += getHtmlFor(i++); container.innerHTML = html; N transactions versus 1 transaction. I mean that compiling separate N "small" DOM access calls is not always faster than one integral update.
- acdha 3y ago
  My point was that that is enormously slower than storing a reference to the elements when you create them and setting only the specific attributes which changed. innerHtml string parsing forces the browser to do too much work unless you’re literally changing everything. Each time I’ve replaced that with DOM operations it’s been an order of magnitude or more performance gain - on one project, getting rid of fully-optimized React was 4 orders, but I think they’ve optimized it enough since then that it’s only 1-2.