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?
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.
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....
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.
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?
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.
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.
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 ;)
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
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.
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.
It's up to the browser implementers how they do tables, and they certainly could go ahead and cater to common cases in this area. As user agents, it's the browsers' job to be helpful to the user regardless of what the HTML looks like.
For example, nothing in HTML talks about having a search prompt appear on Ctrl+F, yet everyone does it.
HTML does not have a table component because it is a markup language, and that kind of interactivity (sorting, filtering, pagination etc) is really beyond its scope. The exception to this are basic user input fields (buttons, check-boxes etc).
This is by design, browser vendors are focused on implementing low level APIs and functionality, leaving the higher level component development stuff up-to web developers and designers.
Use a combination of JS, CSS and HTML to create advanced components from scratch, or use one of the thousands of open-source libraries available. The library linked to in this post is a good example of that.
> It's up to the browser implementers how they do tables, and they certainly could go ahead and cater to common cases in this area.
True. But especially lazy rendering and fixed column headers seem to be within HTML's remit. Fixed column headers should probably be a new CSS rule, and lazy rendering should just work by default.
Nice distinction! Although I'm not sure "trolling" is a fair dig. My comment was genuine.
When I wrote my first HTML page you could make them out of basic <TABLE> tags and nobody would beat you over the head with a styleguide for doing it wrong. I found them approachable if you followed some basics like avoiding nesting, and with care, dynamic sizing went a long way. But I understand some people are zealously against them (for good reason). CSS addressed several of the shortcomings but introduced new complexity and gotchas. My frustration is that instead of evolving to simple, elegant and approachable syntax, we landed in a place that calls for a library to patch in those attributes on top. (And now I'm greeted with bank statements that dynamically add content as you scroll, making it impossible to cut and paste the data from a spreadsheet).
None of that takes away my admiration for the author's work, I'd just prefer a world where the hole filled by this library didn't exist in the first place :-).
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!
>> 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.
> 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.
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!!
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 ?
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.
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.
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.
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: