[hajile]

React is very far from the fastest vdom. It notably suffers from needing to work with non-DOM back-ends where a particular heuristic that is good in the DOM may either be useless or (worse) actively degrade performance. Preact, Snabbdom, or Inferno would probably be better points of comparison to Svelte's approach as they are much more optimized for the web.

DOM nodes can actually be recycled relatively easily. Cache the nodes by type then by class. Most recycled nodes would be a 100% match based on those two alone. If type and class match, then you have a super-high probability of dealing with old nodes for the same object, so few modifications are required. Most nodes without classes tend to have no attributes changed (<div>, <p>, etc) so they will match as well. Store those nodes with their vdom attached and you will have a record of what has been modified so patching is fast.

This optimization exists in some vdom implementations and would make the case in question much faster. There also seems to be an implication that the diffing algorithm will bloat. If you look at React, the diffing algorithm is a very small part of the codebase.

This is hardly just an academic optimization though. It is the key to reducing overhead on long lists. With long lists of complex objects, you cannot rely on patching text values because there will undoubtedly be actual DOM differences. Rather than dooming the entire list to poor performance, you can recycle those nodes and retain most of the performance of a flyweight scroller where nodes are all identical.

https://developers.google.com/web/updates/2016/07/infinite-s...

[daliusd]

Either I have completely misunderstood you or you are simply wrong. It looks like you are implying that vdom is magical solution to long lists and svelte should have problem here. While in real world we have this: https://svelte.dev/repl/f78ddd84a1a540a9a40512df39ef751b?ver...

[hajile]

Like most other scrollers, the svelte one tries to only show the elements on screen plus a couple above and below to keep up the illusion. The Google article makes it very clear that top performance requires re-using DOM nodes.

In that very simplistic example, there are only 4 nodes to each list, so creating and destroying them doesn't matter. I have a scroller in a business app where each item has a few hundred DOM nodes. Create and destroy them constantly and you'll definitely notice on a desktop and performance will crawl on a mobile device.

Instead, you want to save those DOM nodes in a cache and re-use them. In order to do this though, you must know what parts are default and what parts have been modified by their previous user. A vdom does this automatically, but the cost for Svelte to calculate which of the hundreds of properties have changed is too big, so they just throw it away and make another.

An even better optimization would be where each list item has the same node structure and only text or images change. I believe Svelte can handle this case. Unfortunately a lot of lists are slightly irregular in real-world applications. I work with these kinds of lists a lot and a vdom keeps it smoother than all the other libraries we've looked at.

[daliusd]

I don't see what stops you adding caching in Svelte for virtual lists.

[hajile]

Imagine you add a few attributes, some properties, and a couple event listeners to a node. In order to reuse the node, you have to reset it to factory settings.

How would Svelte know what things had been changed when looking at a node saved in a cache?

If it has to check every property, the cost to check will exceed the cost to create new. If it saves a list of changes, it's essentially created a vdom anyway.

[daliusd]

Thank you for explaining that to me. It is good to know what technology to use if I will meet this specific case. So far all projects I have worked on can be implemented both with React and Svelte :)

[shortercode]

Last time I tried keeping a collection of simple DOM nodes to "recycle" my perf tests showed it was slower than just creating new nodes. So I wouldn't necessarily consider this an optimisation, although memory use might be better.

[hajile]

It depends on how you recycle them I guess. One of Inferno's biggest optimizations (according to its creator) is the reuse of DOM nodes and vdom fragments. To my knowledge, it's still the fastest vdom implementation around.