Although Grid.js is currently designed to work with web-browsers, I’m actively thinking and working on adding other integrations like React Native (see https://gridjs.io/docs/philosophy)
Please let me know if you have any suggestions or comments. Happy hacking! :computer:
Great work - really clean documentation, and it looks beautiful!
We currently use `react-table`, which is good in that it can support some reasonably large datasets (for instance, here's 2 million rows on the client-side - https://datapane.com/leo/reports/table-test/ - a bit laggy with sorting, but passable). This may not be the use-case you're going after at all, but have you run any benchmarks for how big a dataset you can support?
Thanks for submitting and great work so far. The tables it makes definitely look nice.
I must admit though, I have a hard time imagining where I could use this right now.
Good responsive handling of tables is the most difficult part of using (nonmassive) tables effectively in 2020 and is far and away the main reason I would consider taking on a table library dependency on a project but there doesn't seem to be any effort put in on this front.
A table is most useful when you have horizontal space to make use of and information to fill that space, and when you don't you almost always want to replace it with a list that takes advantage of vertical scrolling. Every application should work well on mobile (yes, every application) and it doesn't look like there's anything here for that yet.
I don't often deal with massive datasets but I wonder why, if I was, I wouldn't just use one of the many existing, mature, performant datagrid components that are already available if I did... This one looks good but if all it does is very small and simple data sets I'm afraid it doesn't seem terribly useful, because for a table with only 2-3 columns which this component seems to be designed around, I could just do it myself and get a fine result in an hour or so in Angular, including a mobile view version that dumps the table or hides unnecessary columns.
Speaking of Angular, "works in" Angular is surely true but would I use it in Angular when I had to handle wrapping it in a component myself when plenty of other more powerful options exist which already integrate very well into Angular?
There's so many other nifty features to be had around sticky table headers and rearrangeable columns and HTML templated cell types and optional columns hidden automatically on mobile that are absent or at least not exampled, and I would love to take a look once more of the obvious features are added and mature but right now it feels like a library for newer developers who are not yet comfortable with the fundamentals of tables. It's like bootstrap but only for tables...
I think you have a lot of promise in this lib but there's a lot of work to do before I'd use it.
It looks like sorting / pagination is all down client side which forces a download of all the rows, how well does this support tables with 10s or 100s of thousands of rows?
The documentation is lacking a section header "see also" that explains the differences to prior art/similar software. A programmer cannot tell whether Grid.js provides an advantage over e.g. https://backgridjs.com without wasting a lot of time on experimentation.
Good effort! I'm not sure how 'advanced' it is though. I'd even go as far as call it 'simple'?
E.g. the following features would be required to make it advanced (list not complete):
- Export data (csv)
- Align columns based on their content
- Tree data (parent/child rows)
- Total rows
- Formatting applied based on data type (currency, numerical etc.)
- Reordering columns
- Resizing columns
- Hiding columns
- Optional filter field for every column
- Conditional formatting
- Tripple Sorting & Multiple sorting (sort by more than 1 column at a time)
- ... more
In the react world, I found this to be a good foundation for an 'advanced' table. Since it's rather inconsistently developed, I ended up forking it for myself and working on my own copy, removing unneeded elements and enhancing with everything else I do need.
I agree that Grid.js is not a full-featured plugin _yet_ and it's still missing essential features, like those that you mentioned but please bear in mind that:
- I have only released the first version of the library.
How accessible is Grid.js? The main differentiator between table libraries for me these days is accessibility. Many libraries and frameworks out there do it poorly. The better ones are often tied to company-specific frameworks.
From playing around a bit, I've at least noticed that sortable headers have no focus indicator, the "sort column ascending" text gets included in the column's accessible name, and un-sortable column headers are read as clickable by screen readers.
I would LOVE a framework-agnostic table library that's both lightweight and fully accessible. If there's a chance for Grid.js to take this in its philosophy, I would be all in!
> The better ones are often tied to company-specific frameworks.
That is because to implement accessibility in a grid/tree widget to a meaningful level, you need a lot of underlying code. Even in modern browsers. Source: implemented accessibility in Ext JS framework.
One of the most often asked questions from users of Ext JS was: hey, can we have the Grid widget without all the bloat? Sure, and ~95% of the framework exists so that the Grid can have its features and work reliably across all the browsers. You can probably do without the rest 5%, no biggie.
I just created a ticket to work on this aspect of the library soon. I'd appreciate if you add your comments to https://github.com/grid-js/gridjs/issues/25 if you think there is any specific components that needs immediate improvement.
I have, it's amazing. The only thing it's missing is drag and drop to outside divs. Other than that, it's feature rich, very customizable and the best from all other js grids I tried.
I'd say the claim "works everywhere" does not consider small screens. I had a look at the examples with Android Chrome in portrait viewport, and cell content gets either cut off with ellipses on overflow, or breaks long words such as email addresses unintelligibly over several lines.
In my opinion, scrollable-by-touch tables such as Bootstrap 's "responsive tables" fix these issues. Add "scroll for more" shadows for even better UX.
- Grid.js is a data-processing pipeline (see https://github.com/grid-js/gridjs/tree/master/src/pipeline) which enables you to easily extend the library
- It's framework agnostic!
- It is written in TypeScript
- Fully tested and documented
Does anyone know why HTML tables can't natively support a lot of common table functionality? Lazy rendering, fixed column headers, sorting and so on? Are there any proposals to add all this natively?
I think a bit part of HTMLs success is not being too opinionated about more advanced/specific UI components. Think of it more of as a low level GUI toolkit constructor, one to builg actual GUI toolkit on top of, for example material-ui and bootstrap.
Good, I like framework agnostic components. I've been playing with two other libraries recently: Dropzone js and Sortable js. Grid js looks useful too.
Looks awesome. We just tested vue-tables-2 yesterday but the lack of customization is making it hard to implement. This looks very promising, I’ll be taking a look again tomorrow!
Do you plan on releasing special themes or options for css frameworks like bootstrap 4? I had a quick look on my phone so I apologize if this is already available.
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?
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!
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)
Hey, nice grid. Please consider multiple column sort / grouping. It will suddenly make it like analytics tool... And if add some statistical functions... Maybe too much for client side, but who knows
I am so glad I put off making the frontend for my project. It's literally all tables, and I didn't like how DataTables functioned. So glad you made this and looking forward to trying it out!!
[+] [-] afshinmeh|5 years ago|reply
I’m Afshin, the creator of Grid.js.
Grid.js is an open-source table library written in TypeScript and published under MIT license.
My goal is to develop a framework agnostic table library that:
- Works everywhere. You don’t need a specific framework to use Grid.js
- Lightweight and easy to use
- Fully documented and tested
- Developer friendly. Grid.js is written in TypeScript! Supports all modern web browsers
Please take a look at the examples (https://gridjs.io/docs/examples/hello-world) section and let us know if you have any suggestions.
Although Grid.js is currently designed to work with web-browsers, I’m actively thinking and working on adding other integrations like React Native (see https://gridjs.io/docs/philosophy)
Please let me know if you have any suggestions or comments. Happy hacking! :computer:
[+] [-] pea|5 years ago|reply
We currently use `react-table`, which is good in that it can support some reasonably large datasets (for instance, here's 2 million rows on the client-side - https://datapane.com/leo/reports/table-test/ - a bit laggy with sorting, but passable). This may not be the use-case you're going after at all, but have you run any benchmarks for how big a dataset you can support?
[+] [-] simonw|5 years ago|reply
Any idea why the columns aren't displaying correctly for wider tables? Take a look at this example:
https://observablehq.com/@simonw/grid-js-with-datasette?url=...
[+] [-] irrational|5 years ago|reply
[+] [-] rezonant|5 years ago|reply
I must admit though, I have a hard time imagining where I could use this right now.
Good responsive handling of tables is the most difficult part of using (nonmassive) tables effectively in 2020 and is far and away the main reason I would consider taking on a table library dependency on a project but there doesn't seem to be any effort put in on this front.
A table is most useful when you have horizontal space to make use of and information to fill that space, and when you don't you almost always want to replace it with a list that takes advantage of vertical scrolling. Every application should work well on mobile (yes, every application) and it doesn't look like there's anything here for that yet.
I don't often deal with massive datasets but I wonder why, if I was, I wouldn't just use one of the many existing, mature, performant datagrid components that are already available if I did... This one looks good but if all it does is very small and simple data sets I'm afraid it doesn't seem terribly useful, because for a table with only 2-3 columns which this component seems to be designed around, I could just do it myself and get a fine result in an hour or so in Angular, including a mobile view version that dumps the table or hides unnecessary columns.
Speaking of Angular, "works in" Angular is surely true but would I use it in Angular when I had to handle wrapping it in a component myself when plenty of other more powerful options exist which already integrate very well into Angular?
There's so many other nifty features to be had around sticky table headers and rearrangeable columns and HTML templated cell types and optional columns hidden automatically on mobile that are absent or at least not exampled, and I would love to take a look once more of the obvious features are added and mature but right now it feels like a library for newer developers who are not yet comfortable with the fundamentals of tables. It's like bootstrap but only for tables...
I think you have a lot of promise in this lib but there's a lot of work to do before I'd use it.
[+] [-] w-ll|5 years ago|reply
[+] [-] dandare|5 years ago|reply
[+] [-] fbnlsr|5 years ago|reply
[+] [-] bmn__|5 years ago|reply
The documentation is lacking a section header "see also" that explains the differences to prior art/similar software. A programmer cannot tell whether Grid.js provides an advantage over e.g. https://backgridjs.com without wasting a lot of time on experimentation.
[+] [-] hazz99|5 years ago|reply
[+] [-] naveen_|5 years ago|reply
[+] [-] hn_1234|5 years ago|reply
[+] [-] XCSme|5 years ago|reply
[+] [-] Bishonen88|5 years ago|reply
E.g. the following features would be required to make it advanced (list not complete):
- Export data (csv)
- Align columns based on their content
- Tree data (parent/child rows)
- Total rows
- Formatting applied based on data type (currency, numerical etc.)
- Reordering columns
- Resizing columns
- Hiding columns
- Optional filter field for every column
- Conditional formatting
- Tripple Sorting & Multiple sorting (sort by more than 1 column at a time)
- ... more
In the react world, I found this to be a good foundation for an 'advanced' table. Since it's rather inconsistently developed, I ended up forking it for myself and working on my own copy, removing unneeded elements and enhancing with everything else I do need.
https://material-table.com/
[+] [-] afshinmeh|5 years ago|reply
I agree that Grid.js is not a full-featured plugin _yet_ and it's still missing essential features, like those that you mentioned but please bear in mind that:
- I have only released the first version of the library.
- I have been focusing on fundamental blocks of a lightweight _data processing_ library (see: https://github.com/grid-js/gridjs/tree/master/src/pipeline). That's what took most of my time.
- Grid.js is framework agnostic which is a bit different compared to other libs
The pipeline is very easy to extend and I'm confident that most of those features will be added soon.
[+] [-] bubbab|5 years ago|reply
From playing around a bit, I've at least noticed that sortable headers have no focus indicator, the "sort column ascending" text gets included in the column's accessible name, and un-sortable column headers are read as clickable by screen readers.
I would LOVE a framework-agnostic table library that's both lightweight and fully accessible. If there's a chance for Grid.js to take this in its philosophy, I would be all in!
[+] [-] nohuhu|5 years ago|reply
That is because to implement accessibility in a grid/tree widget to a meaningful level, you need a lot of underlying code. Even in modern browsers. Source: implemented accessibility in Ext JS framework.
One of the most often asked questions from users of Ext JS was: hey, can we have the Grid widget without all the bloat? Sure, and ~95% of the framework exists so that the Grid can have its features and work reliably across all the browsers. You can probably do without the rest 5%, no biggie.
[+] [-] afshinmeh|5 years ago|reply
I just created a ticket to work on this aspect of the library soon. I'd appreciate if you add your comments to https://github.com/grid-js/gridjs/issues/25 if you think there is any specific components that needs immediate improvement.
[+] [-] ipsum2|5 years ago|reply
[+] [-] danseagrave|5 years ago|reply
[1] http://www.tabulator.info/
[+] [-] btzll|5 years ago|reply
[+] [-] Keyframe|5 years ago|reply
[+] [-] joaodlf|5 years ago|reply
[+] [-] thrownaway954|5 years ago|reply
[+] [-] Eduard|5 years ago|reply
In my opinion, scrollable-by-touch tables such as Bootstrap 's "responsive tables" fix these issues. Add "scroll for more" shadows for even better UX.
[+] [-] rootcage|5 years ago|reply
[+] [-] afshinmeh|5 years ago|reply
Also please take a look at https://gridjs.io/docs/philosophy.
[+] [-] boromi|5 years ago|reply
[+] [-] triceratops|5 years ago|reply
[+] [-] orange8|5 years ago|reply
[+] [-] rkagerer|5 years ago|reply
[+] [-] huhtenberg|5 years ago|reply
Obviously nobody NEEDS to resort to that. However there's a difference between
and which is what this lib is for.[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] hendry|5 years ago|reply
https://git.codemadness.org/jscancer/files.html for more goodness
[+] [-] sliptype|5 years ago|reply
I've worked on projects that had very intense excel-level requirements for their data grids and ag-grid was a dream.
[+] [-] afshinmeh|5 years ago|reply
[+] [-] guggle|5 years ago|reply
[+] [-] silviogutierrez|5 years ago|reply
I'd love to use this for the table to come rendered from the server then hydrate on the frontend and enable AJAX pagination, etc.
Completely understand if you can't, after all, you'd likely need to more tightly integrate with ReactDOMServer.
[+] [-] afshinmeh|5 years ago|reply
[+] [-] byteshock|5 years ago|reply
Do you plan on releasing special themes or options for css frameworks like bootstrap 4? I had a quick look on my phone so I apologize if this is already available.
[+] [-] mason55|5 years ago|reply
Have you pushed the rendering performance at all to see how far you can get without scrolling getting painful or seeing tearing artifacts?
[+] [-] mstade|5 years ago|reply
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!
[+] [-] denster|5 years ago|reply
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.
[+] [-] fedd|5 years ago|reply
[+] [-] ggmartins|5 years ago|reply
[+] [-] OJFord|5 years ago|reply
- ellipsis (good there is one) breaks between second and third dot. I think the easiest fix for that is to use an actual ellipsis character.
- break between page '3' and 'next'
[+] [-] yingw787|5 years ago|reply