Offloading virtualization to the browser via CSS Containment

[mihkeleidast]

Hey all! I'm trying to understand how much benefit there still is to actually render virtualized lists, versus using CSS content-visibility on the lists instead? To me it seems that both approaches want to help the browser work faster by not rendering offscreen content.

But as react-virtuoso (and other virtualization libraries AFAIK) still do all of the work in JS, I wonder what the benefit of that is? Has it been benchmarked in some way? Usually native solutions, especially moving this kind of functionality from JS to CSS results in the best performance.

I guess there may still be some wrapper library around CSS Containment necessary, to measure the items and set contain-intrinsic-size, etc, but if we could remove a bunch of JS by using CSS features instead...

Edit: Seems that the browser support ain't too good yet.

[petyosi]

I was very optimistic about this spec when it came out. As much as I love my work, in the ideal world, the browser should support this and Virtuoso should be obsolete and I can retire :).

CSS containment must help with the browser rendering performance, but you will still have to fetch all data from the server and render it with React - which is a lot of work, most of the time. One can probably handle that with intersection observers and lazy conditional rendering/data fetching, but then you lose the native find feature.

This being said, perhaps there's something in there. Maybe not a whole lot of it, given that intrinsic size still has to be managed.

[morzel85]

While modern browsers can easily display scrollable panels with thousands of elements (engines are smart enough to skip processing of elements that lay outside of visible area) we should still try to avoid large DOM (waste of memory, slower selectors, really bad impact on devtools performance etc.). The more important thing is that browser can do its tricks only after React does its rendering (runs the components) and this could be prohibitively slow, especially in grid scenarios (100x100 is 10K components).

Maybe one day it will be built into React somehow (Intersection Observer API?) so component rendering will be automatically skipped if it would not be visible anyways (but how about sizing?)...

[mihkeleidast]

Is the large DOM really still an issue even if we could bypass the render of offscreen content?

Virtualized rendering comes with its own set of issues, for example the hidden content is not available in the accessibility tree and also not in in-browser search.

I personally don't think it's an issue that should be solved in React, such virtualization in general is something we should try to get rid of to improve accessibility and user experience. There are probably some edge cases where the list/grid is so big it makes more sense to virtualize and solve the accessibility issues manually (like a world map), but I honestly think that most of us should not need virtualization as such.

[morzel85]

I wish we never have to do virtualization, but it's still often necessary especially in enterprise applications where there's a need to display data from sources you don't control or the UX is not negotiable (regulatory requirements, legacy systems etc.). I've had to render trees of 150K accounts or show editable grids with 200 rows and 500 columns. Virtualization made it possible.

[lalexdotcom]

The point is that Virtuoso is preventing two things: rendering (the React part) and painting (the DOM/Browser part)...

Virtuoso is already able to know where to place content (using padding-top for Virtuoso or empty tr+td for TableVirtuoso), so, in a perfect world where every browser supports content-visibility, maybe it could prevent the react render and place some empty div/tr+td for each item to preserve an identical DOM structure, and use content-visibility to optimize painting?

The pain point is browser support 😓