Show HN: Datagridxl2.js – Fast Excel-like data table library (datagridxl.com)
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!
107 comments
[ 4.6 ms ] story [ 29.9 ms ] threadI'll definitely be using on a project soon. Really love the elegant docs and the API.
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.
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.
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.
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
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 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
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.
Disclosure: I am the primary developer of Glide Data Grid.
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
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.)
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 :-)
Does it support formulas?
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?
https://www.datagridxl.com/demos/import-csv-data
https://www.ag-grid.com/javascript-data-grid/massive-row-cou...
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.
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.
- 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.
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/
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 :)
[1] https://ds.gpii.net/connect/testers
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.
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.
[0]: https://github.com/6pac/SlickGrid/wiki/Examples
[1]: http://6pac.github.io/SlickGrid/examples/example-spreadsheet...
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.
https://www.datagridxl.com/buy
Free if you don't disable the branding link.
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.
Can it be used as a front end with say C++/C# etc to replace Excel COM interop?
Without the calculator aspect it not really an excel clone.