Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Grid.js – Advanced table library that works everywhere (gridjs.io)
390 points by afshinmeh on June 4, 2020 | hide | past | favorite | 132 comments

Hello folks :wave:

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:

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! Appreciate your feedback.

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.

Congrats again on a beautiful product.

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.

I'm playing around with it in an Observable notebook here: https://observablehq.com/@simonw/grid-js-with-datasette

Any idea why the columns aren't displaying correctly for wider tables? Take a look at this example:


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.


> Oh great!

The correct response :-)

Awesome :)

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)

Hey Simonw! I fixed both issues with the column/table width and published v1.1.1. See: https://observablehq.com/@afshinmeh/grid-js-with-datasette?u...

Please take a look and let me know what you think!

That's awesome - fast turnaround too! Thanks for the fix.

I'd like to see an example of a very wide table (maybe 30 columns). I want to see how it would look on a phone in portrait mode.

Sure! I'm currently working on this one and will push a fix today.

That’s something I would never like to look at on my phone tbh

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

Some users will be irrational

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

Out of all the ways the table library designers have tackled this issue, which one do you think is the least bad?

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.

when you say "server-side" do you mean this is typescript that runs on the server? thus requiring a node-based server?

Not necessarily, any HTTP interface that can return JSON (e.g. Python Flask, PHP, etc)

I am excited to use the vanilla JS version in my project, thanks for not being React only :)

Definitely going to try this. I've been using Datatables with Vue but it's not the most user friendly. Thanks for your work!


> Fully documented

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.

This looks fantastic! I'm going to start using it immediately. Thankyou for your hard work.

It's not mobile friendly.

Is there any load testing benchmark results available. if so can you share ?

I haven't created a performance report yet but I will definitely create one and add it to the docs. Good point.

Your documentation is really cool, what did you use to make it?


Looks like it's made with Facebook's Docusaurus.


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.


Thanks for your feedback.

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 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 do appreciate being framework agnostic. I think more common components like this would benefit from being built that way.

Checkout Frappe Datatables (https://frappe.io/datatable) (MIT License) it has most of what you need.

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.

That makes sense. thanks for the feedback.

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.

It seems like you know a lot about accessibility, have you considered contributing to the library?

Has anyone tried Tabulator[1]?

[1] http://www.tabulator.info/

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.

That feature will be coming soon :)

Yes and it's fantastic. Integration with React has a few quirks, but otherwise great.

Yes! Tabulator is amazing.

Agreed! It has been my go-to javascript table library for a while. Can't say enough good things about it.

That being said, Grid.js looks like a nice upstart project. I will have to keep my eyes on it

doesn't have the styling pizzazz, but man is this thing feature rich! thank you for posting.

It comes with a load of built in themes if you are looking for a shinier look: http://tabulator.info/examples/4.6#theming

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.

Out of curiosity how is this better than current Grid/Table implementations?

- 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

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

A similar product is https://datatables.net/

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"

datatables uses jquery, though.

Yep, it's got more functionality at this point. I wonder if the author of Grid.js could incorporate the added functionality.

From user point of view, datatables can do much more than Grid.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.

That doesn't really answer the question though.

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.

They already have, via the <table> tag (https://developer.mozilla.org/en-US/docs/Learn/HTML/Tables/A...).

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.

This looks really cool although I find it disheartening that we need to resort to JavaScript simply to construct a decent table.

You are trolling, mate.

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.
which is what this lib is for.

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 :-).

https://codemadness.org/datatable-example.html is the lightest version of sortable table in JS i've seen.

https://git.codemadness.org/jscancer/files.html for more goodness

This looks nice but much less configurable than ag-grid.

I've worked on projects that had very intense excel-level requirements for their data grids and ag-grid was a dream.

Agreed. This is the first version of the library though. I will definitely add more core plugins and configurations soon. Stay tuned!

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 great! Any plans to support SSR in say, the React use case? useEffect won't run on the server and obviously you don't have the DOM.

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.

That makes sense. SSR should be possibly and relatively easy to achieve. I will create a ticket.

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,


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.

You’re right, I forgot about forms – good shout!

> 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)

[1] You can see how we render large grids at

https://mintdata.com/docs in the example sections.

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 like https://www.npmjs.com/package/react-data-table-component but this one looks cool too. Maybe a dense mode?

FYI on my small mobile screen (iPhone SE) the demo:

- 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'

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!!

Congrats! Curious why you haven't considered https://react-table.js.org/

I am trying to use linking in one of the columns. Looks like using links breaks the table. Any idea if linking column data is supported out of box?

Do the cell values have to be primitives? Embedding pure JS inside a React app is easy but using React inside pure JS is usually where the trouble is.

They don't have to be. I will definitely test this particular case.

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 is a bit different, let me explain.

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.

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.


I'd suggest doing the up/down arrows in css instead of images, the images look a bit blurry on retina screens

Good point. I will definitely change that part.

On a related note, I glad to see unpkg.com offically supported. Being able to avoid npm install is just nice sometimes.


How does this compare to competitors like Ag-Grid?

One simple feature I see lacking in the ability is the ability to resize columns

Good job! Looks great.

What about performance? Have you tested how many rows can Gird.js handle without a noticable lag?

Thank you!

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.

Anyone have thoughts on how to support the following in ReactJS

-Sortable columns

-Multi-select filters in columns

-expandable rows

Tabulator should support pretty much all those things, it really is a fantastic library.

This doesn't render well (it's a malformed input, but still) -

    const grid = new Grid({
      columns: ['A', 'B', 'C'],
      data: [ ['1', '2', null, '(353) 01 222 3333'] ]

Does anyone know of something like this but with editable cells?

jqGrid, DataTables, ag-Grid, jQuerygrid, ... a lot. How many grid libraries do we need?

Tabulator, has most of the features of AG grid and is totally free http://tabulator.info/


The best I’ve used so far. quite pricey, but worth it

Not pricey if you are ok with the open source MIT version.

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.

Tried to run in my atari 800XL - didn't work :P

What benefits does it have over mat-table?

I disabled JavaScript and it doesn't load the table.

I unplugged my toaster, but it doesn't work?

Sure, except the major point is this, Progressive Enhancement [0].

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

it looks like it can:


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.

If you don't use software that parses and displays HTML, then plain HTML tables won't work either.

It’s an enhanced data table.

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

That would be a good idea for this table. Privacy conscious people like me would welcome this.

This is surely a satirical comment?

Nope, many people (sadly technical people) browse the web without JS turned on.

It makes the web a whole lot faster with no scripts running. (especially on mobile)

Are we just buy a domain for a library now?

I like to turn JavaScript off for these sites

I thought this was about CSS Grid, but nope, nothing at all to do with that.

Maybe read the welcome message again: https://news.ycombinator.com/newswelcome.html

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

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact