Show HN: Grid.js – Advanced table library that works everywhere

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?

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=...

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.

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.

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.

Also please take a look at https://gridjs.io/docs/philosophy.

Obviously nobody NEEDS to resort to that. However there's a difference between

    ... simply to construct a decent table.

    ... to construct a decent table simply.

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!

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.

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.

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.

But, I guess that could be a feature to allow your data tables to fall back to some static table.

It could help you construct a more thoughtful comment next time. It's the most important principle and really simple to pursue.