That is exactly what I came here to say as well. In my datatable custom query layer, I can pull down 1 million rows and view them instantly displaying them in a continuous list on the client, lazy load related table rows, and neither the web client nor the traditional web server on a traditional SQL Server, where I dynamically build the queries and can filter on any column, break a sweat. And the server is on 10 year old hardware that still runs spinning disks and the clients are often older lower powered computers. And that's with me not optimizing performance, other then thinking about it lightly up front. EDIT: Yes, the tables are sometimes medium wide, 20-50 columns buffered on the client on those rows.

I think because their whole original logic was client side - to generate a filtered view would require loading all the data in the client first and then applying a filter.

Or just re-query the server with the new filters applied.

Works fine until you try to do it on a mobile device

mobile will crash the page simply off memory use, esp older phones

You're right, a modern browser can handle it without issues using virtual scroll [0].

[0] https://shlomiassaf.github.io/ngrid/demos/virtual-scroll-per...

Virtualzing (or windowing, as it is sometimes called) is definitely one way to tackle this problem. However, it's not a silver bullet. The more complex the UI/rendering is, the more optimizations you will need. The demo you link shows a very simple rendering with no complex user interactions, mouseover events, etc.

It’s a solved problem. Things like aggrid allow you to use virtual scroll with custom components for your preferred framework, some simple efforts towards optimising the css and dom complexity would be more than enough.

Agreed. Obviously you shouldn't render all of that, just keep it in memory and render the rows that are scrolled into view.