5 ms·

One of the issues we find is that as the number of rows/columns in a table grows, the performance of native browser tables just craters and you have to fallback

One of the issues we find is that as the number of rows/columns in a table grows, the performance of native browser tables just craters and you have to fallback to your own rendering engine using <canvas> elements. Have you pushed the rendering performance at all to see how far you can get without scrolling getting painful or seeing tearing artifacts?

mstade 6y ago
How many columns/rows can you realistically fit in screen? Isn’t this practically solved for most use cases by just having as many as needed for rendering and replacing contents as necessary? 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!
- SloopJon 6y ago
  > How many columns/rows can you realistically fit in screen? 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.
  - mstade 6y ago
    > Give me a sort key or two, a filter box, and I'll whittle it down to what I'm interested in. 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.
- at-fates-hands 6y ago
  >> Grids really feel to me like a rite of passage for front end developers, 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.
  - mstade 6y ago
    You’re right, I forgot about forms – good shout!
denster 6y ago
We [1] used to think the same thing a few years back, but then figured out empirically that virtualization (above the React layer) will let you view/scroll through virtually unlimited-size datasets (until you hit the browser's memory limit per tab). 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 https://mintdata.com/docs in the example sections.

mstade 6y ago

How many columns/rows can you realistically fit in screen? Isn’t this practically solved for most use cases by just having as many as needed for rendering and replacing contents as necessary? 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!

SloopJon 6y ago
> How many columns/rows can you realistically fit in screen? 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.
- mstade 6y ago
  > Give me a sort key or two, a filter box, and I'll whittle it down to what I'm interested in. 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.
at-fates-hands 6y ago
>> Grids really feel to me like a rite of passage for front end developers, 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.
- mstade 6y ago
  You’re right, I forgot about forms – good shout!

denster 6y ago

We [1] used to think the same thing a few years back, but then figured out empirically that virtualization (above the React layer) will let you view/scroll through virtually unlimited-size datasets (until you hit the browser's memory limit per tab). 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 https://mintdata.com/docs in the example sections.