Have you pushed the rendering performance at all to see how far you can get without scrolling getting painful or seeing tearing artifacts?
I’ve worked in financial institutions for going on a decade at this points and there are grids everywhere. I’ve learned a thing or two about them in these years and that’s:
- everyone wants to implement their own, for reasons
- they’ll mostly do a decent but not quite good job at it, because it’s complicated and oh hey let’s just all forget about accessibility (traders love keyboard navigation!)
- performance is always a problem till someone reinvents virtualized row rendering
- excel beats your thing anyway and everyone knows it so if you just have decent excel import or even just good paste handling you’ll do fine
- 99% of grids people actually use never show more than two dozen rows or so, and then implements pagination and just like with google no one ever goes to page 2 of the results
If you have a pressing need to handle thousands/millions of rows, it’s likely not for display but for editing, in which case:
1. Just use excel
2. Virtualized rows still has your back, ain’t no screen showing more than maybe a hundred rows or so anyway, and even if it did no one reads that far
Grids really feel to me like a rite of passage for front end developers, along with a basic charting library and mildly interesting application framework. Incidentally, this is also how I’ve landed most of my jobs, so maybe I’m biased.
EDIT: This is by no means a dig at the author and I’m sorry if it may come across as such! This library looks like a fine piece and I wish you every success!
I don't know why you think many rows is an indication that you're editing. Tables are the first resort for reports, and reports tend to have lots of data (i.e., rows).
While I'm not a fan of horizontal scrollbars, I absolutely prefer to render thousands of rows with a vertical scrollbar than use pagination. Give me a sort key or two, a filter box, and I'll whittle it down to what I'm interested in.
I've seen Airtable show up on some sites lately, and its scrolling performance is abysmal. None of the examples for Grid.js has more than a handful or rows, so I won't take its performance on faith. So far, DataTables has been my go-to option for web tables, but I'd happily switch to something else if it performed as well.
This is also editing, albeit of the view of the data, maybe I should’ve made clear that that’s what I meant (primarily, anyway.) Thanks for challenging!
Grids with massive amounts of data are – in my experience – only used to build models, i.e. sort, filter, aggregate. No one cares tho read more than a couple dozen or so rows, but they do like the ability to chuck a ton of data into the grid and then edit the view by applying various combinations of functions to sort, filter and aggregate the data into something that is more fit for purpose. You don’t need a grid to apply functions to data, it just happens to be a pretty effective interface to do so. But it’s only effective if rendering is fast, and that means someone somewhere will again reinvent virtualized rows. Or you know, just use excel.
Agreed!
The last two jobs I interviewed for the code challenge was a) hit this API endpoint, b) pull the data and put into a table and c) make said table responsive and accessible.
The majority of front-end work these days is either forms or tables. Get good at both and you'll have steady work forever.
So, at this point, I would say canvas is not required to render large grids in modern browsers (even though Google Sheets does this for likely legacy reasons)
[1] You can see how we render large grids at
https://mintdata.com/docs in the example sections.