Show HN: Datagridxl2.js – Fast Excel-like data table library | Hacker News Reader

Show HN: Datagridxl2.js – Fast Excel-like data table library

datagridxl.com

301 pointsrobbiejs104 comments

I'm Robbert, the creator of DataGridXL.js. Last month I released version 2 which includes many new features.

DataGridXL is a free (and commercial) editable data table library written in ES6.

My goal is to develop the most performant & user-friendly spreadsheet-like data table out there:

- It has zero dependencies. You don’t need any framework to use DataGridXL. - It is lightweight (~250kb) and easy to use. It does not even require messing with CSS. - It has its own Virtual DOM implementation to prevent DOM errors. - Developer friendly. Supports all modern web browsers

Please take a look at the performance demo (https://www.datagridxl.com/demos/one-million-cells) to see the difference with other data grids out there. And let us know if you have any suggestions.

Please let me know if you have any suggestions or comments!

Open articleView on HN

Accessibility is a strong gating factor for some (including me). I don't see it in the docs. The whole thing seems to be missing any ARIA (see https://www.w3.org/TR/wai-aria-practices/examples/grid/dataG...) Let me know if you want help.

Do you happen to know of best practices for simulating different disabilities, or some recording of somebody actually using some example well-designed accessible software? A video recording, to me as somebody who can see and hear and move just fine (for now), would help me understand what interaction methods don't work or are a struggle, which interaction methods are intuitive and effective, and which types of content are not recognized, not presented, or not important.

Lighthouse [1][2] Accessibility audit/ scores can be a good tool to check A11Y issues automatically, and it is fairly easy to integrate into your CI/CD Pipelines to get the report automatically to check for issues/ regression.

The web accessibility world is complex enough that simulating different methods of access like using screen readers or different font-sizes and doing manual tests for compliance is not particularly feasible if you want to make your content accessible to all.

[1] https://developers.google.com/web/tools/lighthouse [2] https://web.dev/accessibility-scoring/

I disagree. Automated results are not perfect and miss a lot of nuances, like element ordering, tab indexing, etc. Assuming you can’t find someone experienced with a screen reader to test I would invest in learning how to use one yourself. I’ve spent days without access to my screen in order to grow more comfortable navigating with audio. Of course, I won’t be as helpful or quick as someone who’s used a screen reader for years, but it’s better than blindly trusting lighthouse/web.dev

> but it’s better than blindly trusting lighthouse/web.dev

Interesting use of "blindly". Using lighthouse or other accessibility checkers is better than not considering accessibility at all, and has a much lower barrier for developers and development orgs than integrating screen readers into the development lifecycle.

I was in an org where our QA team actually used our sites with screen readers, and yet we still ran automated accessibility tests on our codebase. This is because we can catch issues earlier and more easily, and reduce the amount of issues making it to manual QA which is much more time consuming and expensive.

Manual QA testers using screenreaders are also not perfect and miss a lot of nuances :)

Some time ago I helped building https://ds.gpii.net which actually features a lot of ressources for developers regarding accessibility. It has a component search that links most of the automated testing tools ( scraped and curated from GitHub. ). I think actually videos of assistive tech use would have been a nice addition, but there is already a lot of so called quicksheets to get you started. One USP we wanted to have is a community of testers [1] unfortunately it did not really happen at the time (there is a form though for matchmaking): Anyone interested to continue the work on this kind of stuff should probably contact Gregg (Vanderheiden , who I guess wrote the first web a11y guideline back in the 90s and is a WCAG editor).

[1] https://ds.gpii.net/connect/testers

Thanks for your feedback. It's true, I have not made any real efforts when it comes to accessibility (apart from choosing DOM over Canvas). I would very much like to make DataGridXL as accessible as I can, but right now it is not a priority. Thank you very much for sharing the link, that looks really helpful. Are you experienced in making data grids accessible?

I've done a lot of work on data grid accessibility. In fact, DataGridXL is one of the many grids I considered for our own needs a couple years ago. The reality here is unless you somehow export out a DOM structure which has an element per cell, for at least the cells that are on screen, you will never be able to get the screen reader to behave correctly. If you were using a canvas you could export a subdom on the canvas, but with the approach y'all take with the line-height + dom node per column I don't see how you get there.

The cell nodes need be browsable and selectable by the screen readers caret. You could do what many other DOM based grids do and add an "accessibility mode" but I believe accessibility should be the default and not a mode people turn on as a checkbox. Let me know if you want to chat, I'm always happy to share what I know. I'm by no means an expert but I've definitely picked up a thing or two.

Seems pretty much impossible to not have an accessibility mode yet have features such as fixed columns/rows. It would be very difficult to have a clean DOM structure while supporting that layout. If it is possible I'd be very interested in how that is done.

It can be done if you are using a Canvas to provide the rendering. The canvas can then be provided with a subdom that does not render but is visible/interactive to screen readers which matches exactly what the screen reader requires. Canvas's actually have the advantage here if they put the effort into being accessible.

You could do the same trick by hiding the visible DOM from the screen reader and creating an invisible DOM explicitly for the screen reader. If your DOM structure is wrong for the screen reader I would suggest doing this.

This is amazingly nice it works for mobile and that is great

Ah thanks, we'll be improving touch controls soon (adding a mobile contrxt menu)

Congrats on the release.

For those looking for a FOSS alternative, I haven't seen mentioned here yet Toast UI Grid - TUI-grid: https://ui.toast.com/tui-grid

I've been using it for over a year and it works perfectly.

The performance here is amazing. Well done!

I'm desperately searching for a way to replace old Handsontable (before they closed source), but the license here for DataGrid XL makes it impossible to easily bring into a large FOSS project.

Some ideas for licensing: dual license MIT and commercial. Feed advanced features and support into the commercial while keeping the MIT version fast, performant, extendable.

I think it was handsontable I burned myself on: got client to sponsor/pay for support for a nice open source tool and shortly after they went closed source.

Same with caddy, except that time it was my money.

Some times I wonder if I should avoid giving money to open source projects because it seems to trigger the idea that one can make a whole lot of more money by selling out.

You can still browse the source on GitHub though. I don't mind them trying to make more money so much. What I don't like is that we have 3 bugs open, one of them 3 years old, that aren't getting fixed. And paying for a license didn't give us any additional priority.

It's also not very performant. Rendering often forces multiple style/layout recalculations, which is nearly always solvable by having your rendering code better organized. Version 8, when they rewrote cell meta, caused certain cell meta APIs we were calling to take _seconds_ on large tables. Version 9 did not document that the "beforeManualColumnMove" changed the meaning of the indices from "before columns" to "after columns". Undo/redo is implemented incorrectly too, so we had to write that ourselves. These caused real problems that affected our users.

As soon as we get the capacity to switch to something like Datagridxl2 we will.

Handsontable made at least $1.5M https://www.indiehackers.com/post/how-to-earn-1-5m-in-revenu... . Whether that's "a whole lot" is questionable.

What? Caddy has always been Apache-licensed, open source. And that's thanks to sponsorships which make it possible.

Maybe Caddy was technically Apache licensed the whole time but it sure didn't feel like. And I have a hard time believing that feeling was not intentional.

If you are still looking to replace Handsontable then AG Grid community edition is free, open sourced and MIT Licensed. The AG Grid commercial Enterprise edition has more advanced features and support.

Please point out wether it is free or commercial in your announcements :

https://www.datagridxl.com/buy

https://github.com/DataGridXL/DataGridXL2/blob/master/LICENS...

Free if you don't disable the branding link.

I'm impressed by the lack of dependencies and single-file download.

One of my use-cases is for offline use, and not via a web app installation -- only assets in an ordinary filesystem directory. Mega-components in single js files are a good step towards that.

> not via a web app installation -- only assets in an ordinary filesystem directory

Not sure I understand this. Every web app I build is just a set of HTML/CSS/JS files that are served in a static fashion, which means that you could just plop that static folder onto your hard drive, click "index.html", and interact with it normally. I guess routing concerns maybe exist if you just naively hope the URL-based-routing works but it'd be easy to work around this

Perhaps I was attempting to refer to progressive web apps, with manifests and such.

Thank you. Wanted to keep it simple and lightweight. Not the biggest fan of an average React/Angular project with 200mb+ of dependencies.

Been using AgGrid but looking for a replacement. I tried to load a CSV of 100k items here and got a "RangeError: Maximum call stack size exceeded."

https://www.datagridxl.com/demos/import-csv-data

What is motivating you to look for a replacement? We are evaluating grids and AgGrid is the front runner currently though really rather heavyweight for our use cases.

All things considered it’s great software but yes it can be kinda heavyweight at times.

Would you mind taking a look at grid.glideapps.com and letting me know if/where it doesn't work for you? We are always looking for feedback. Development is done entirely in the open, feel free to just file issues and open discussions on github.

would be so awesome if Glide was easy to package into a Svelte project!!

AG Grid should be able to handle more than that:

https://www.ag-grid.com/javascript-data-grid/massive-row-cou...

I haven't tried using DataGridXL with a file with that many records. There is a chance that the DOM node that is used for scroll-listening grows too large and browsers cannot handle that. I suspect that is where the error comes from.

However, I will add this to our list of issues, see where the error really comes from and where I can improve it (https://github.com/DataGridXL/DataGridXL2/issues/31). For now, I would say 10,000 records max to be sure.

There is a million record demo? That is where my confusion comes from.

one million cell demo (2000 by 500)

We ran into the same issue! We actually implemented a feature we joking call clown-car scrolling to handle this. If you want to steal the basics of it you can see it here: https://github.com/glideapps/glide-data-grid/blob/main/packa...

Feel free to steal and improve, we only enable the clown-car mode when the desired scrollable area is larger than what a browser can support. With our implementation scrolling is still handled by the browser, but the scroll location can be subtly recomputed as you go from time to time. We only do this when interacting with the scrollbar directly to avoid weird artifacts like scrolling feeling faster than normal.

"Maximum call stack size exceeded" is probably a general bug, not an issue that appears due to trying to load too many rows. Unless they really did something crazy, each new row shouldn't add to the call stack.

I looked at a bunch of grid libraries a few months ago and ended up settling on revogrid. give it a look, it's fairly similar to ag grid, though I don't know much about its large dataset performance (my use case was getting a good user friendly editing experience for a smallish number of rows, at most a few hundred)

Hey Robbert, just want to say congrats on this! This is excellent work and really thoughtful / detailed.

I'll definitely be using on a project soon. Really love the elegant docs and the API.

Thank you! Appreciate it very much! Let me know what you're working on when you get to it! robbert at datagridxl.com

I think you're half way to why users stick to excel.

Without the calculator aspect it not really an excel clone.

The catch phrase on the homepage gives the wrong impression I believe. Thanks for pointing that out. I am not trying to create an Excel clone, but rather an editable data table with Excel like controls and interface.

This caught my eye. We are in the market for a high-quality gridview component that would allow for in-line edits. We also looked at CSV in/out, but having something integrated could be better. The UX would have to be on-par with excel and this seems close.

My biggest question right now: What does integration of Datagridxl2 look like when operating with a Blazor Server app? Should I just expect some basic JS interop when building a wrapper for the component?

I do not know anything about Blazor Server app or how it works. DataGridXL is all about client-side interaction: mouse events, touch events, keyboard events etc, as such it cannot function on a server alone, if that is what you mean.

Looks interesting. I've just been looking at a couple of alternatives to this. We're adding a CSV import feature for our store finder, and the idea is to provide a spreadsheet-like interface where you can just copy and paste your location data instead of uploading a CSV where you need to deal with different delimiters and getting the column orders right etc.

You might be better off with something like https://csvbox.io/

Interesting, thanks for sharing!

If your up for jQuery-ui see SlickGrid examples[0] especially "Spreadsheet: features of the previous example but using a DataView"[1].

[0]: https://github.com/6pac/SlickGrid/wiki/Examples

[1]: http://6pac.github.io/SlickGrid/examples/example-spreadsheet...

Cool, thanks for sharing!

Wonderful work! If you think your table is the best, as someone who is pondering buying it, you'd save me some time if you had a quick comparison matrix with your main competitors. It seems counterintuitive to provide that but most people will do the research anyway so you're just saving them some time searching and cataloguing alternatives.

Thank you. I did have an article on the site that compared DataGridXL with Handsontable, but we had to take it offline since HoT lawyers were not happy with it (you can read a discussion about that here: https://news.ycombinator.com/item?id=30503983). Anyway, it's a good idea. I will create one with Handsontable, Ag-grid, anything else?

>most people will do the research anyway

eh, most people will prefer the first product they see - so by the time they get to competitor X, they just dont have the energy to do a full sweep of details. Especially if the first one had everything they were looking for and after a couple other searches their pricing doesnt seem unreasonable either

You might enjoy this site: https://jsgrids.statico.io/

How does it compare with https://grid.glideapps.com/ ?

Looks quite similar to me. Both are using canvas (combined with off screen rendering?) under the covers which seems to be key to achieving this level of performance.

No reason to sacrifice accessibility and styling in the name of performance: https://github.com/jpmorganchase/regular-table

Funny. I just rolled my own datagrid for a portion of a larger application that already uses DataTables for various stuff. I wanted something that acted like this, was fast and allowed for easier row and column styling (including in the data itself). Also, faster and more flexible animated resizing.

I ended up using CSS grid divs and without any virtualization on my part, they're shockingly performant. Both Chrome and FF easily handle 1m cels which is more than my use case will ever need. They're really quick at blitting just the necessary cells, making it wayyy smoother than DataTables in virtual mode. And anything on an actual canvas tag...? forget about it.

Glide Data Grid has a fully accessible DOM subtree. No need to sacrifice accessibility just to use a canvas. Come on, its 2022 we have the tools. What makes Canvas even nicer is I can export a subdom that is bespoke for screen readers. It is exactly what the screen readers want, nothing more, nothing less. It works wonderfully.

Disclosure: I am the primary developer of Glide Data Grid.

DataGridXL actually only uses canvas for cell background colors (when you use the search bar) and for measuring text width. Everything else is DOM, just not <table> with individual cells.

Or tabulator http://tabulator.info/ .. I don't see filtering though.

I was recently evaluating a few of these to display large number of items (tabulator, aggrid, custom solution using react-virtualized etc)

Unfortunately if you are planning to use tabulator (in an enterprise environment for example), I would advice against it for a few reasons:

- No tests (atleast I did not find them when I looked into it)

- I dont normally critique the codebase but I found it to be a bit unorganized and that did not inspire confidence. Basically I found it be non DRY. However I found it easy to understand and make changes

- Being developed by one person and I found little support and response when I raised issues and PR

We've been using tabulator for few years now on an internal project. It's been doing quite well so far, has a lot of features out of the box and is easy to customize.

To balance my critique, I would add that I found that tabulator had support for most number of features out of the box of all that I tested and was the easiest to customize

One million cell made me though of https://lumino.readthedocs.io/en/latest/examples/datagrid/in... that has a "trillion" cell demo :-) All the best.

With a virtual data model it doesn't really matter, here's our 2 trillion cell model https://bl.ocks.org/texodus/483a42e7b877043714e18bea6872b039

I wonder if this kind of ux is just for fun, like let me scroll through and have no actual sense of data. At the end of the day, finding something is via search and filter.

>You don’t need any framework to use DataGridXL. - It is lightweight (~250kb) and easy to use

I'm not so sure 250k qualifies as lightweight by any definition. That's a pretty high target even for total bundle size. React, for example, is ~6k.

Okay, gotcha. Maybe I should mentiod that it is lightweight compared to other options. Handonsontable is a terribe 1.5MB. I imagine Ag-grid is close to 1MB as well.

How long did it take you to build OP?

I love the simple design, just one thing: consider adding to #header .menu-btn:checked ~ .nav larger max-width and some margin to .buyMenuOption, since .buyMenuOption button gets covered by the .nav div on smaller screens: https://i.imgflip.com/6c1c7a.jpg

What's a good FOSS alternative to this for non-commercial projects? I'd like to have a spreadsheet on my site for personal use.

AG Grid, SheetJS both have decent community editions.

I'm biased because I'm the maintainer, but canvas-datagrid is a, uh, canvas-based datagrid (https://github.com/TonyGermaneri/canvas-datagrid), which can easily handle millions of rows. It's FOSS, and although in need of improvement (and better type annotations), it's well-documented (https://canvas-datagrid.js.org/) and actively maintained.

FWIW, I went through a bunch of these libraries recently for a personal-site spreadsheet as a react component. All I wanted was a grid where each cell was a calculation based on the combination of its row/column header values. I kept running into the problem where the data grid library gave me 90% of what I needed, a different 90% each time. What actually ended up working perfectly for me was react-table and just using hooks to do the formula calculations.

I maintain https://grid.glideapps.com if you're looking for something ludicrously fast.

I have noticed your product before, very well done!

Thank you! DataGridXL has been my text only benchmark for a long time because of how ludicrously fast it is! Downright creative problem solving!

Ah thanks, yes, had to make some uncommon design decisions, all for the sake of performance. I am impressed that you managed to create a performant product with all the advanced rendering too.

Very nice!

Just, I'm not sure that users who stick to Excel despite a web app do so just because of Excel's interface... sometimes it is because it is much easier to work with files than with web sites. And sometimes the way to get to the web app is the thing destroying the UX (slowly responding servers, weird login processes, etc.)

Ah yes I see what you mean.

I used to work for a fintech startup and our sales team had a hard time finding customers for the product that we're building. These customers were impressed by the web app that we've made, but "we don't see a reason to use your products, we are used to Excel and we like Excel". So we decided to create a page in our web app that looked like Excel. I initially used Handsontable for this page. I was so disappointed with its performance and its reliability, that I decided to create DataGridXL. Anyway, that's the story and that's where the "slogan" comes from :-)

Thanks for sharing this :)

I would like to invite you to share Datagridxl here: https://forums.haydenjames.io/c/showcase/21 (will be suggested to subscribers)

This looks very nice! I am looking for a spreadsheet like component for a project I am working on. Had evaluated jspreadsheet before. Question I have is, how would one go about integrating formulas and references? The demo doesnt seem to support that.

Hi, I am not sure if the product will support formulas. I 'll let it depend on popular demand. For now, DataGridXL does not support it.

I'm looking for a version of the is that supports pagination from a db backend so you don't have to load all the data to the frontend at once. I need a read only spreadsheet with lots of data. Does anybody have any suggestions?

Have you considered writing the component using canvas? The fastest full featured grids I encountered, incl. google sheets, are based on canvas.

Yes I have considered canvas. Parts of the grid are canvas (cell background colors).

I chose DOM for a bunch or reasons: natural font scaling was a big thing (easy on the eyes even if zoomed in all the way) and another big thing was that working with canvas was difficult for me, even workin with a canvas you would have to apply lots of tricks in order to get the performance.

I do believe my DOM approach is faster. The rendering is a faster than Google Sheets.

This look really good.

Can it be used as a front end with say C++/C# etc to replace Excel COM interop?

No it's not a replacement for Excel and its huge set of features, instead it implements an Excel-like interface to edit csv, json or js array data. No formulas, pivot tables, merged cells.

Can't see any mention of multisort. Does it have multisort? Great look and feel!

For now it's single column sort but I plan on adding multi sort soon, don't have a specific date for it yet, but possibly q2 or q3.

How does it compare to sheetjs?

One feedback, undo is currently slow even if I just want to undo 5 cells of data.

Can you tell me what webpage you're on (and your device+browser). Undoing should happen instantly.

Default Grid, filled all 9 cells, and hold undo until all clear. I'm on Firefox 99.0b8 (64-bit), 4 GB RAM. I said it's slow but it's not really, it's like 200ms lagging for each undo.

I will look into it, thanks for letting me know. Have you tried Instead of holding undo, try to press it once?

Is there anywhere to view original (not minified) source?

Is it as fast as the demo with custom cell renderers?

Hi, we have not implemented custom cell renderers yet. Also, for performance sake, we decided not to render HTML in cells. So not sure if DataGridXL can offer you the things you're looking for at this time.

Congrats, it looks amazing!

Does it support formulas?

Hi. An early build did, but I decided to leave out the feature as there is much more to it than I thought. Perhaps in the future, 2023 or 2024 stuff.

-"You've built a web app, but your users stick to Excel" I feel that if your users are not using your web app, it's not because they miss the (dated, not exactly intuitive) Excel interface. Seems to me like the wrong solution for the problem

For a fintech startup I was working for, that was the feedback our sales team got. "We like the product and it looks impressive, but we're used to Excel and we like to use Excel". So that's when we decided to add a page in our web app that had an Excel-look. That did not change things, the product vision was wrong, just like you said. But I can imagine that more web app producers get exactly this feedback from their prospects.

I miss many things about the Excel interface in early every web app:

- editing many records as a table

- formulae for calculating values

- ability to paste from other tables or Excel sheets

- information density!

- arbitrary sort and filter

- hiding and rearranging columns

- etc…

Every app with search, including search engines themselves, and most with data entry should have an Excel-like, table based interface. GitHub discovered this (just look at their new projects) and most data focused apps are no exception either. Terminal utilities, Python scripting, and JSON are sometimes as good or better, but more often a poor second place.

Reply on news.ycombinator.com