Hacker News Reader

Comment by TekMol | Hacker News Reader

    Until a while ago, when a user landed on their
    board, we threw all the board data right into
    the client (usually a web browser running on a
    desktop computer).

    the client is limited in its resources. Depending
    on the client device and board structure, it
    started to struggle and finally, crashed after a
    few thousand items (“table rows” in monday.com
    terminology). If we really pushed it, we could
    handle up to 20k items. Beyond that, it was game
    over.

This does not make sense. Why would a browser not be able to handle more than 20k table rows?

I have not tested it, but I would think juggling arrays with a few million entries should not make a browser sweat.

View on HN

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.

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.

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

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

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

Reply on news.ycombinator.com