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:
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?
Correct. I have a PR ready which integrates the sort, search and pagination with the server-side module. Currently, there is a Server Side module that pulls data from the server (https://gridjs.io/docs/examples/server).
Quick tip: for the client-side, large dataset case, if you want to get fancy it's possible to create a worker thread and perform the sort there, which makes it somewhat faster but more importantly stops it from freezing up the tab while it operates. We did this to great success at my last company when we needed to sort ~200,000 items client-side. The UI thread remained perfectly responsive during the operation and we were able to present the user with a loading spinner while it worked.
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?
Well, it is on our roadmap! With Grid.js you will be able to sort, search or process data in a separate thread (Web Worker) and then pass the results to the main thread to render.
I'm also thinking about lazy-loading the table rows. Both the Web Worker bit and lazy-loading will be added in a week or two.
Cool! Have you checked out https://github.com/bvaughn/react-virtualized too? Might be totally useless to you, but I think they've done a lot under the hood to optimise table loading.
I’ve used react-virtualized to render hundreds of thousands of rows, it’s a great library. React-window from the same developer is also worth checking out if you don’t want all the bells and whistles.
Oh great! I guess the columns are not properly rendered because there are a lot of columns. That looks like a bug to me. I just created two issues and will release a bug fix soon.
I took a look at it appears the observable notebook has a stylesheet defined with a table element style that sets a table's max-width to 640px. That is why it is not expanding to fill the width. (I am not associated with the project)
But, someone is going to try to do it. Tables on a large screen are easy. The real test of how good a table library is is how it handles small screen sizes. Some libraries drop out columns. Others switch to a vertical format. Some just let scrollbars handle it. I can think of about 10 different ways this is commonly handled. I'd like to see how this library does it.
Yeah but I don’t think there is an instant where showing more than 4 columns on a mobile is readable. I think this lib still squeezes it into the viewport, gotta set minWidth manually. Pretty standard
And you cannot please every irrational user. There just no good way to show wide tables on a narrow screen. It’s like trying to transport a load which exceeds the dimensions of its truck. Sure you can in theory drive it if it doesn’t collapse right away but that doesn’t mean you should.
I as a frontend developer think that tables simply are not made for a portrait mobile phone. Needs a different UI concept, e.g. cards in a vertical list. That way it is possible to show all info at the same time, while only having to scroll one direction. Tables which exceed the window width and height are terrible to use.
Tables are naturally wide while phones are naturally narrow. Why try to make it fit? Reminds me of the kid which tries to cram a star shaped piece of wood through a round hole.
I’m not saying the table library must make it fit. But the table library must address the issue. Having the library convert the table into vertical cards is a perfectly acceptable solution. But the library must handle doing that.
I can see that this is not a common do which libraries do because the decision when to break it down into a new component and how that is structured still requires some human thought. There is no one-size-fits-all yet, sadly.
All apps should work well on mobile. If you have a use for a table at all, you must also consider how it works for a mobile user. Whether that means dropping columns, replacing it with a list, handling horizontal scrolling or whatever, you should be doing it. If you pull in this library and then have to do that yourself, why not just implement the table yourself, since getting the advanced features like paging to work in such a dual view setup (table on desktop, list on mobile) would likely be more work than just making a table yourself....
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.
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.
- 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
With Grid.js you will be able to sort, search or process data in a separate thread (Web Worker) and then pass the results to the main thread to render.
I'm also thinking about lazy-loading the table rows. Both the Web Worker bit and lazy-loading will be added in a week or two.
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!
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.
> 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.
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.
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.
What's the "Advanced" part in this ? Vue/quasar tables already provide extensive functionality and I am sure there are react and angular alternatives.
I don't think there is a need for a library to work across vue/react/angular at the same time because no single person is going to use those in a single project.
I appreciate the project since I am frequently looking for js grid implementations but what the differentiator here ? Is it performance or styling or flexibility or just variety of frameworks ?
There absolutely are advantages to libraries that work independent from, or across multiple frameworks. Most webdevs have experience with multiple frameworks. It’s nice knowing you can use a library in whatever project you’re working on.
Grid.js has an internal pipeline library which takes care of pulling the data, adding data processing layers, caching each layer when it's possible (e.g. you search for a keyword and then you navigate between pages) and running the steps to refine the data.
The `pipeline.process()` can be executed in a different thread than the main browser thread (e.g. Web Worker) which is super useful to perform the CPU consuming bits.
Unsure what differs between the two functionally, but it appears that library is ~3x the size for js+css (~12kb vs ~30kb) compared to Grid.js. It looks like it might use jQuery too? Or at least, the CDN is "jquery.dataTables.min.js"
I've found datatables to be my only real solution when dealing with lots of server side data. It has it's quirks for sure, but there really isn't anything I haven't been able to accomplish with it so far (although making it do what you want sometimes can involve some head scratching).
Edit: I see http://www.tabulator.info/ mentioned in the comments. This looks pretty full featured... time to do some research.
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!
> 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.
> 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.
>> 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.
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)
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.
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.
I don't doubt that you can and possibly will make this a great library. It seems like a nice and clean foundation for one. I just commented on the word 'advanced' in the title. You admitted yourself that it's missing essential features, so advanced might be an adjective you'd want to use for release 2.0 ;)
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!!
134 comments
[ 0.19 ms ] story [ 208 ms ] threadI’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:
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?
Well, it is on our roadmap! With Grid.js you will be able to sort, search or process data in a separate thread (Web Worker) and then pass the results to the main thread to render.
I'm also thinking about lazy-loading the table rows. Both the Web Worker bit and lazy-loading will be added in a week or two.
Congrats again on a beautiful product.
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=...
Thanks!
The correct response :-)
Please take a look and let me know what you think!
Looks like it's made with Facebook's Docusaurus.
Tables are naturally wide while phones are naturally narrow. Why try to make it fit? Reminds me of the kid which tries to cram a star shaped piece of wood through a round hole.
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.
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.
It could help you construct a more thoughtful comment next time. It's the most important principle and really simple to pursue.
Also please take a look at https://gridjs.io/docs/philosophy.
What about performance? Have you tested how many rows can Gird.js handle without a noticable lag?
With Grid.js you will be able to sort, search or process data in a separate thread (Web Worker) and then pass the results to the main thread to render.
I'm also thinking about lazy-loading the table rows. Both the Web Worker bit and lazy-loading will be added in a week or two.
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!
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.
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'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.
It makes the web a whole lot faster with no scripts running. (especially on mobile)
This table is useless if it doesn't load without JS, especially if it is a table that claims to work everywhere.
[0] https://www.gov.uk/service-manual/technology/using-progressi...
https://gridjs.io/docs/examples/from
specifically, data rendered as an html table that is then "transformed" in javascript.
if I'm reading the example correctly, then this is how to have progressive enhancement with this module.
But, I guess that could be a feature to allow your data tables to fall back to some static table.
I've worked on projects that had very intense excel-level requirements for their data grids and ag-grid was a dream.
[1] http://www.tabulator.info/
That being said, Grid.js looks like a nice upstart project. I will have to keep my eyes on it
I don't think there is a need for a library to work across vue/react/angular at the same time because no single person is going to use those in a single project.
I appreciate the project since I am frequently looking for js grid implementations but what the differentiator here ? Is it performance or styling or flexibility or just variety of frameworks ?
Grid.js has an internal pipeline library which takes care of pulling the data, adding data processing layers, caching each layer when it's possible (e.g. you search for a keyword and then you navigate between pages) and running the steps to refine the data.
The `pipeline.process()` can be executed in a different thread than the main browser thread (e.g. Web Worker) which is super useful to perform the CPU consuming bits.
My main focus has been designing the pipeline and will continue to improve it. Also, the pipeline can be extended easily (see https://github.com/grid-js/gridjs/tree/master/src/pipeline) and steps are pure functions.
Edit: I see http://www.tabulator.info/ mentioned in the comments. This looks pretty full featured... time to do some research.
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.
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.
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/
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.
- 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'
Also their modular system is very easy to extend so you can always write your substitute adapters for their enterprise code without even forking it.