Show HN: Datagridxl.js – No-nonsense fast Excel-like data table library
datagridxl.com
datagridxl.com
I’m Robbert, the creator of DataGridXL.js.
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 (~200kb) 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!
Is there a UI way to quickly sort by a column?
I haven't really thought of filtering yet, but it's very likely that one day we'll introduce a filter-option. However, at this moment I cannot say when.
I've just released a new version that adds a Sort Feature to the grid: https://www.datagridxl.com/demos/sorting-columns.
I am actually working on a sort feature at this moment and I expect to release at the end of the week.
I've just released a new version that adds a Sort Feature to the grid: https://www.datagridxl.com/demos/sorting-columns.
There are a few products out there that implement formulas. A site like www.jspreadsheets.com mentions a few. Many of these products are not super-reliable or performant though (reason why I started building DGXL in the first place).
The table has a complex layout:
- One fixed top row (date), two or three fixed columns on the left.
- Data are rendered horizontally; the number of rows does not change, but the number of columns can be in the hundreds.
Does your library support column-oriented data like this (you mention "60+" columns)? Does anyone know of any library which can easily render something like this? It's surprisingly hard to find something which lets you fix left hand columns and also render as many columns as I need.
The component actually did have fixed/frozen columns/rows in an earlier version, but I decided to leave out the feature for a v1. I plan to reintroduce it after more popular features have been implemented.
DGXL is able to handle hundreds of columns. The reason why it says 60+ specifically is that, according to browser-vendors like Mozilla, a DOM node should ideally not have more than 60 child nodes - for performance/memory reasons.
When scrolling horizontally, column nodes are appended/preprended on-the-fly. The old ones are only removed if the scrolling stops (until that time, column nodes that are outside the viewport are just made invisible by setting their opacity to 0).
If a user scrolls really fast without stopping in between, they might have 200 column nodes in the DOM. The DOM nodes are then only removed when scrolling stops.
Performance wise I haven't seen any problems with 200 columns or more.
Here's their excel like example showing 200 columns: https://bl.ocks.org/texodus/3e0e3d6f8bf8b47294a7847b402b55fb
There are many commercial and open source products on the market, some more established and less expensive than your offering. From the business standpoint, it's easy to sell something like ag-grid because many developers have experience with its open source offering, so we know that we can find experienced people on the market to help if necessary. Your project doesn't benefit from that community and doesn't benefit from having a lower price point (it's comparable to what ag-grid charges)
CSS Scroll Snap?
Nicely done.
I initially created scroll snap to replicate desktop version of Excel & G. Sheets behavior. I agree that it is not the best option for smaller viewports/touch. It's on my todo-list to introduce smooth-scrolling as well, so that scrolling DGXL on touch will work closer to native apps.
You're probably browsing the site on your phone, am I correct? I created scroll snap to replicate desktop version of Excel & G. Sheets behavior. I agree that it is not the best option for smaller viewports/touch. It's on my todo-list to introduce smooth-scrolling as well.
There is a blank DOM node "scrollArea" in front of all others that catches the native JS scroll event.
It then converts these scroll offsets (scrollTop and scrollLeft) to cell/viewport coordinates, by default 40px actual pixels per row/column.
So if the scrollArea has a scrollLeft of 40px and a scrollTop of 200px , an underlying DOM node that renders the cell values and column lines, will render at viewport position {x: 1, y: 5}.
The other important part that makes it snappy, is that a viewport of let's say 20 rows by 10 columns does not actually consist of 200 DOM nodes. Only columns are DOM nodes. The values inside a column are made to look like rows by CSS white-space property. So it only updates 10 DOM nodes when scrolling.
This does not happen when you paste when the editor is not open, am I correct?
The current solution that I came up with: replace \n with Return HTML-entity. Not sure if that is the best solution for you (or anybody else) but at least it prevents the unwanted shift of column contents.
Thanks again!
const nextColumnIndex = scrollDeltaX < 0 ? Math.max(0, columnStart - 1) : Math.min(columnStart, columnCount - 1);
const columnWidth = getColumnWidth( nextColumnIndex );
scrollBar.scrollLeft += (scrollDeltaX < 0 ? -1 : 1) * columnWidth;
CSS Scroll Snapping may have a place for image gallery sorts of widgets, but for broader layout matters I strongly recommend against it: it can work tolerably on mobile (though it’s not without problems), but on desktop it seriously messes with scrolling so that on many devices it’s almost entirely problems.
Using a real scrolling area and observing what effect scrolling has upon it is the only correct way of rendering things. Then you could draw the contents in various ways—canvas (handle interactivity yourself), another DOM element behind the scrolling area (ditto), or a fancily-done `position: sticky` element that fills the visible part of the scrollable area.
Just remember that there are serious accessibility concerns about any of these sorts of things. Approach any sort of clever lazy loading of content with extreme caution.
Css native's scroll-snap was not useful in my case, but in the end DGXL's custom scroll snap was one of the easiest parts of the product to build. It was one of the things I really wanted to get right.
Using a <table> tag would always be best for accessibility reasons, but it's not an option if you want to create a performant data table with thousands of rows. I am still using HTML, not Canvas, so it is accessible, but it needs improvements.
A great relief is that this is an input-component first of all, to be used in admin-areas. So there's no need for SEO-compatible HTML.
Also, I need to draw a line somewhere. I cannot turn the product into a spreadsheet, as I have chosen for performance as my main feature, which means it cannot do things like merged rows, merged columns, etc.
So if I'd implement formulas, people might expect more & more features, which I then cannot deliver...
(There are products out there that have basic formula support.)
This looks like a really great (clean and performant) JS library for interacting with data grid. I'll definitely remember to try it for my next side project.
A quick question: is there a way to make only some of the columns read-only in the grid? I looked through the doc [https://www.datagridxl.com/docs/setting-options] and it seems like user actions for columns are all (applied to every column) or none. If DataGridXL.js allows assigning read-only to a subset of columns, it'd be great to add that in the doc with an example.
Thanks for your hard work and especially for allowing others like me to try it for free!
Thanks for your feedback!
Right now there is no such option, but it's definitely on the todos of 2020.
At this moment there are not many individual column options: the goal is to implement validation, formatting, read-only prop, etc. At this moment every column just displays raw values & everything's editable.
Since you're building a library, not a tool, whenever I hire an engineer they'll automatically be using this tool and I'd need to remember to send you more money. The only other products that I have to do this with are either:
1. Monthly subscriptions that automatically charge me the correct amount of money.
2. GitLab which tracks how much I owe the developer and charges me the correct amount of money the next time around.
I'm concerned that I'll pay for this software, download a .js file, check it into my repo, hire a new developer, and completely forget they're using this product.
The biggest difference between this tool and my currently paid-for software is that it has no "check-in" period. I could very easily imagine a scenario in which I violate your license. Here are two:
1. I, as an engineer on a single project in a large company, buy your software and use it in a product. I move on to other stuff and get asked to write new features after a long time completely forgetting your software was paid-for. Me and another engineer start working on the project. We now have 2 devs.
2. Another engineer sees me building a cool project. They copy my frontend as a starter for another feature. We now have 2 devs in a multiproject license.
3. We have the correct multi project license for the correct number of devs but we want to hire some contractors for some cheap work. Hiring these contractors just became a lot more expensive.
As for the pricing, at 54,100 EUR ($62,444.87 USD) for a 50 person team, you're competing with a sizable chunk of an engineers salary. Depending on what part of the world you're in you can pay for 1 quarter to 1 years worth of an engineers time with this chunk of change. It seems you're setting yourself aside from the competition because of performance reasons. If that is the large differentiated factor I'd be thinking the following as an engineering manager:
1. Given the timeline (3 months to 1 year) can I build my own implementation of this product?
2. Given the timeline can I take an open source implementation that has more features, use it until there's a performance problem, then have one of my 10x engineers tweak it to make it perform better?
3. Can I find another paid-for version of this library that will be cheaper? In this very HN post there's another implementation of a similar product with a seemingly similar feature set that is substantially cheaper [0] that is also source available.
So, when I'm crunching the numbers, and have to choose to Build, Tweak, or Buy at a cheaper price, it's hard to justify this product. What makes it even harder to justify the product is the support limitations. The main reason to never choose build or tweak or "buy the cheaper one" is because it won't save you any time. Your support page makes it seem like, however, I'll have to put a lot of time and effort into bending over backwards to make a support request that fits your model. This makes the comparison:
1. Build XYZ and support it
2. Tweak XYZ and support it internally
3. Buy your software and get very non-specific support
Is that possible in your framework?
Also see Features & Limits page: https://www.datagridxl.com/docs/features-limits.
It's a canvas based SpreadSheet. The Grid works with React and Konva - https://konvajs.org/
You can see the demo here - https://rowsncolumns.app/demo
And a whole bunch of features and upcoming roadmap - https://rowsncolumns.app/#features
We are launching formula support with Web Workers soon.
I have been working with DataGrids for more than 4-5 years. So I consider myself at a position to compare HTML and Canvas performance
We went with Canvas because of the following reasons
1. Scroll performance is much better than HTML
2. Drawing on canvas is cheap compared to modifying DOM or attributes
3. Streaming updates are much smoother in canvas as drawing is quick. I had used Canvas as an interface for high-frequency trading
4. Canvas is easy to work with. And with https://konvajs.org/, any React developer will find it at home
5. No more Browser bugs :)
6. Performance tuning is quicker with Canvas
7. In the future, we can decide to use WebGL (using PixiJS)
Some problems with canvas IMO
1. There is no relative positioning :(. It sounds silly, but coming from HTML, any element can be positioned relative to its parent.
2. Styling/Pixel ratio/Stroke - can be hard to figure out first. And the 0.5px crisp stroke workaround on DPR 1 devices. Took me a long time to figure out
How I solved this for DataGridXL:
Only columns are DOM nodes. Rows are not actually nodes, but values are spaced vertically using CSS and with a simple newline (\n) character in between. The grid lines are just that: they're grid lines that are repositioned using CSS animation when the user is scrolling.
This means that when a user is scrolling, the DOM does not have to update by, let's say 20 rows x 10 columns = 200 DOM nodes. Only 10 column DOM nodes need to be redrawn.
That's how DGXL works with DOM & HTML but is still in many cases faster than a canvas implementation. Plus it still is accessible. Try zooming the page or use CTRL+F. You can find and select any (visible) value inside the data grid. No problems there.
Canvas can be made fully accessible and screen reader friendly. See how Google Sheets has done. But yes, its not natively accessible like HTML.
That's why I try to make it clear that DGXL is meant for input, editing values. It's not meant for templating or making tables look all pretty for presentation means.
It was a tough decision I had to make, but in the end I am very happy with it. If people are looking for a data table with 100+ features (including markup), I will gladly refer them to 100 other products. But if they're looking for performance & reliability, I am quite convinced that DGXL is the best choice really.
Cell Editing will be moved to the bottom
Cell-selection handles will be changed.
Formatting Toolbar will be displayed On-demand
Few more enhancements to make it touch friendly. We didnt receive any requests yet for mobile-support. When we do, it will be in our roadmap
I actually made quite an effort to make DGXL work on touch screens. It's not there yet. It's basically read-only on touch for now, but you should have no problem selecting cells and copying values.
It's still possible to enable editing on touch screen, but it asks for a custom <input> element on the page that interacts with the grid, using methods setCellValues & getCellValues. It's certainly possible. Will put up a demo for it when I find the time.
That solution would actually work perfectly well for me: tap a cell and an edit widget pops up.
Both Jexcel and Handsontable are quite excellent when it comes to the amount of features, but they do have the same downsides: their enthusiastic creators implement any feature that they can dream off, ingoring the effects on performance and a growing code base that gets more complex every time.
If you're looking to create a spreadsheet app to compete with Excel or G. Sheets, don't look at DataGridXL. If you're looking for the fastest and most reliable editor for 2D or JSON data sets, choose DGXL :-)
I wanted to tackle the performance & reliability issues mainly. My thinking is that most users won't probably need formulas, merged cells, HTML markup. DGXL really shines for larger data sets. Excellent for numeric data input specifically.
Also, I think it implements Excel/G. Sheets controls a little better: when your users are Excel-experts, but keyboard controls work just a little different then they're used to, that's quite annoying. My goal is to stick as best as I can to the original controls.
The actual values are all in HTML. The benefit is that you can use CTRL+F and values are found and selected. You can zoom the page and text will remain crisp.
The values are not in a <table> tag however. <table> values are sorted y,x (rows first, columns second). DGXL sorts values x,y (columns first, rows second). I have to admit that I am not sure what that means for screen readers: I am not an accessibility-expert at this stage. What I do know is that HTML is better than canvas by default in this regard.
Cheers.
Not sure if anyone is still reading this thread. Just wanted to express that I am very grateful for all the positive responses that we got in this thread and by e-mail.
Also, good news: We just released a new minor version today that adds the much requested Sort Feature to the grid: https://www.datagridxl.com/demos/sorting-columns.
Can't wait for features / extensions!
Until then, have a look at Jexcel, it implements numerous pickers/editors (not all of them mobile-friendly I believe).
* incremental updates, inserts, deletes
* nested grids
* formula based coloring of cells
* column based filtering
Regarding other bullet points:
* Nested Grids: no * Formulas: no / not anytime soon * Column based filtering: not on top of the list, but definitely doable.
I don't know DevExtreme and I have to admit that I find the API Reference a little overwhelming. If I can introduce more ways to communicate between back-end and front-end, I am all for it of course.
Do you think the websocket approach for grid/tables is a common one among web devs? A link to a specific code example would help me understand the approach better.
Thanks for your feedback!
This is a common theme among many widget providers. If you work a little bit with lazarus or delphi, you will understand throughly what I mean.
Now how common is streaming backend changes to frontend using websockets? I would say it is pretty common among the financial industry, streaming trades and quotes directly to the UI. Bloomberg, investing.com and many in-house systems that require live updates probably use this.
Still, DGXL has methods like setCellValues, among others, that let's you update a part of the grid, not the entire grid. And it's super fast because of DGXL's virtual DOM.
Thanks again!
However, have a look at this Codepen example: https://codepen.io/datagridxl/pen/XWXGGGq?editors=0010. It combines amCharts and DataGridXL. Update any value in the grid and see the chart adjust. Quite snappy right?
Https://ag-grid.com
There will always be people that find it too expensive or that find it too cheap.
Even though the product looks like a simple <table> tag; the reality is that I spent 2 years working on it. (I am almost embarrassed to admit it.)
Let's say an employee of your company (or perhaps yourself) is a much better programmer than myself. He/she could perhaps build a similar data table in perhaps 6 months, including all these features that don't meet the eye: keyboard controls, context menus, touch events, virtual DOM implementation, clipboard support on all browsers and devices...
That would cost an employer perhaps 6 months worth of programmer salary, which is, depending on where you are, at least $10,000+.
Then 800 euros is not such a bad deal, I believe. At the same time, I hope it's affordable for solo makers as well.
How would you price the product?
For me, personally, handsontable was too expensive too though (I’m just one guy self funding my project) so ended up going with an open source table component instead.
You'll always lose on one of the other. Ag-Grid and DataTables are perfect for presentation, not so much for Excel-like editing. Handsontable & Jexcel try to implement all features of Excel, at the cost of performance & bugs.
I have to make sure that in my marketing I make very clear that my product won't be able to do X,Y and Z, but it's the best at A,B and C. To prevent disappointed buyers.
I hope I am doing that with my Features & Limits page: https://www.datagridxl.com/docs/features-limits. (Column sorting will be implemented soon by the way. Ignore what the page says.)
I am thinking to add some interactive comparison pages like: DataGridXL vs Handsontable, DataGridXL vs Ag-Grid, DataGridXL vs DataTables, etc... to really show & describe the differences between the products.
Anyway, you're always welcome to use the free version. It only requires that you keep the branding link visible, which might not be too bad for your app
Absolutely agree and the open source alternatives tend to do one or two things only (while HoT, DGXL etc seem to offer a lot more in a single package), so for me, it came down to deciding what exactly do I need and if I need something else, maybe I need to use a different one for that.
> I have to make sure that in my marketing
I don't think you need to do too much over what you already have. Maybe put a bit more emphasis on why the "Reliable" part matters. The little blurb on your page about not messing up the DOM isn't really selling it to me, I just looked at it and thought "yeah ok whatever", but this and performance seem to be two of your main distinguishing factors, so I'd lean on them more. Focus on what makes DGXL special. That's just me though.
> Anyway, you're always welcome to use the free version.
I may give it a try. For my main use case, I think the branding is a bit too in-your-face (it would look out of place inside the rest of my web app -- maybe you can provide multiple styles to pick from, just thinking out loud), but overall it looks great so its definitely getting bookmarked.
In any case, great work!
Perhaps I need to show GIFs of other products to show the numerous ways these products get messy. Anyway, just an idea. Will think about it more, very good point.
You're allowed to adjust the color & type of the branding link, as long as it remains visible :-)
on top of the unimpressive feature set and price, they really dont have a good remote support... like Im just gonna send a json object with nearly 100 million rows.