[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 :)