3 ms·
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
by TekMol 3y ago
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.
- tmikaeld 3y agoYou're right, a modern browser can handle it without issues using virtual scroll [0]. [0] https://shlomiassaf.github.io/ngrid/demos/virtual-scroll-performance https://shlomiassaf.github.io/ngrid/demos/virtual-scroll-per...
- eviluncle 3y agoVirtualzing (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.
- white_dragon88 3y ago[dead]
- robust-cactus 3y agoWorks fine until you try to do it on a mobile device
- wahnfrieden 3y agomobile will crash the page simply off memory use, esp older phones
- kardianos 3y agoThat 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.
- DrScientist 3y agoI 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.
- kardianos 3y agoOr just re-query the server with the new filters applied.
- danjc 3y agoAgreed. Obviously you shouldn't render all of that, just keep it in memory and render the rows that are scrolled into view.