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!
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.
Thanks! I'd to write a proper "How It's Made" article about it in the future, but this is basically how it's done:
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.
There is a bug that is caused directly by this whitespace hack. If you copy two lines of text and paste it to one cell, it displays as two cells and shifts the column content below the affected cell (if the affected cell is in the viewport)
Yes, it is possible to paste cells in excel and shift cells below in Excel. But here the cells are shifted if the corrupted cell is visible and shift back if it's not. Definitely a bug.
Ah I think I know what you mean now. I think you mean when you paste multi-line text inside the cell value editor! You're right, thanks for spotting it!
This does not happen when you paste when the editor is not open, am I correct?
Hi janci, just letting you know that the bug has been fixed. Thank you for spotting it!
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.
CSS Scroll Snapping doesn’t make scroll in steps like the steps() timing functions, it just controls the points that the eventual scroll position will snap to.
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.
If a user is trying to scroll horizontally, we can get the delta and get the scroll direction. Find the column width of the next/prev column and update the scroll property. An implementation can look like:
True, scroll snap does have some performance benefits: fewer moments to update the DOM.
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.
That’s an interesting case because it’s certainly a cool effect, but it’s kind of a cumbersome UX on mobile. It makes it hard to keep track of the columns as you scroll up and down. At a glance it seems like both the Google Sheets and Numbers iOS apps have smooth scrolling instead of snapping.
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.
Thanks for your suggestions. Sorting will be implemented very soon, perhaps this week.
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 have been looking for years for something to replace a custom rendered excel-like table I have.
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.
Yes. Let's say your data grid has 200 columns, but only 10 columns (DOM nodes) are rendered in the viewport. The other 190 columns are cached.
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.
Hi, DGXL does not support formulas at this time and I am not sure if I will implement the feature. I'll let it depend on popular demand.
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).
Maybe one day, but no promises. I did experiment with formulas in an earlier version, and it was promising, but there's a lot of things that need to be exactly right.
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.)
Congrats on launching! This seems like a great product! I have seen use cases where something like this could come very in handy. I don't know if this is useful but I'd be worried about using this library because: the difficult to adhere to pricing scheme, the high cost for the level of market saturation, and lack of quality support.
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
Congratulations on launching, but consider distilling a part of the project and making it available under a free and open source license like MIT or Apache or BSD.
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)
Sure. Input elements are still HTML FYI, we dont use canvas to simulate that.
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
I wish you best of luck. I understand your decision to go with canvas. I have experimented with canvas quite a bit as well, as I could not get HTML DOM performance quite right initially.
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.
Interesting. Wonder how you can get cell level control for styling when you are rendering text nodes. Positioning elements by line-height may not be the best way.
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.
For a moment I thought you were talking about DataGridXL, but your comment is on the canvas grid?
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.
For me, DGXL on iOS lets me select and scroll beautifully, but I cannot actually edit (I guess because the cells aren’t text fields, the device doesn’t know to open the on screen keyboard). So it works very well for output but doesn’t work for input.
You're right, the editor does not open on touch screens in this version.
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.
jexcel is great, it has more features (sorting, formulas, colors, etc)... but those same features are not very performant with many (>1000) rows since each cell is a html table cell. datagridxl looks promising if you need to display lots of data. I'm a fan of any open source data grid library so I'm happy both exists.
What I appreciate about Jexcel is their numerous input methods (like dropdowns and checkboxes). DGXL does not offer these features at this moment.
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 :-)
Great question. I think Jexcel is a great effort. There's also Handsontable. I think Jexcel and Handsontable are pretty similar: they have a lot of features, but also a lot of the same errors: performance suffers and sometimes the DOM or CSS gets messed up after a user drag operation.
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.
So from what I understand this works by displaying data on a JS canvas. How does that work for accessibility? Do screen-readers read the data as if it was an html table?
Hi, it does not use canvas. It uses HTML. Sure, DGXL contains one or two canvas elements, but they're used for measuring strings length and drawing cell background colors.
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.
Unfortunately screen reader support isn't great at the moment, but using HTML instead of canvas is definitely going to make it easier for you to improve. I'd encourage you to download the free NVDA screen reader (https://www.nvaccess.org/download/) and compare DataGridXL with Excel, or Google Sheets with screen reader support enabled (Tools > Accessibility settings). Announcing the column, row and cell content as you navigate the sheet with the keyboard would be a great start. Google Sheets does this by updating the content of a visually hidden ARIA live region (https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...) as you navigate.
That you for this valuable advice! I have to admit that I have never worked on accessibility before (apart from writing meaningful HTML). Will definitely look at improving screen reader support when I get to it.
Right now the free version offers the same features as the commercial version. As long as you're OK with displaying the branding link and DIY-support, you can use the product for free, as long as you like.
Hi, you're right. At this time it's not supported, but we're working on it. Probably next week. The other features are still a definite "no" for now :-)
Yes - that's perfect. So fast and smooth. I have a small side project on the cards that could use this, but unfortunately wouldn't be a paying customer though.
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.
Nice. I read a CSV file with one mutli-line column in the last field with no problem, but when I copied the data, refreshed the page, and copied to empty grid, now the multi-line field incorrectly was split to the next line.
Shameless plug! https://ellx.io/ is a programmable spreadsheet with extended JavaScript for formulas (plus operator overloading and automatic async resolution)
Hi, for an example, check out how the devxtreme datagrid uses a datasource object to manipulate the data in the grid in real time. Which means, instead of loading all the data into the grid before it is rendered at the time of declaration, the data can be appended, updated or deleted as it streams from a backend.
My issue with most grids (and charting libraries for that matter) is that the API is push based (ie they all have some kind of API like setData, etc), instead of pull based (where the grid utilizes an adapter model with simple functions like getRowCount, getColumnCount, getData(row, column) and you can build subclasses that adapt to any data model you have). This means that it's really difficult to implement highly performant grids that support changing data, more data than can fit in the current viewport, etc. It also makes it difficult to share large datasets between different views - ie a chart and table both showing the same data, or two tables showing different sections of the same dataset, without multiple copies of the data in memory.
Not 100% sure what you mean, but it sounds like a "server-side first" approach (if that word exists). As grid & chart libs are always built by (front-end) Javascript experts, you'll always see a front-end first approach.
Ah, sounds good. Do you mean the grid keeps front-end and back-end data synced? DGXL does not offer that at this moment. You could probably recreate something like it by using getData and setData methods and implement some kind of AJAX communication.
The grid itself doesn't proactively try to equalize frontend and backend data, but I utilize backend orm signals to generate websocket events which are then captured by a javascript callback in the frontend and sent to the grid. The grid then updates immediately reflecting the changes. There is no need to send the entire dataset, though, just the changes.
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.
The data source is an observable which triggers changes in the widgets that listen to it. A nice way of avoiding slow widget updates is to disable animations while making big changes to the data source. It also helps decouple UI code from business code. It even gives you the opportunity to react to widget changes such as adding a row or changing a cell without reading code directly from the widget's internal data structures or DOM.
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.
I see. I did spend a few months on a crypto trading platform and they had this frequent-updating table to display latest prices for each currency. DGXL really is an input-first component, so I haven't thought of this websocket approach.
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.
Ag-grid has a lot more features. Very mature, big team I'd guess. However, Ag-grid does not offer quick Excel-like editing. If you're looking for this type of editing, don't bet on Ag-grid.
Thanks, I have seen this suggestion a couple of times now in this thread. Will have to study it, as right now I am a non-expert when it comes to screen readers. Will make an effort to seriously improve this aspect!
Do you think it's too little or too much? This is my first commercial product. I have looked at other professional grids like Handsontable & Ag-Grid and have decided to choose a similar price, just to have some reference.
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.
Handsontable has a lot more features, though. Maybe your unique selling points are enough, I don’t know, just on paper handsontable appears to provide a lot more for the price. I’m not suggesting you change it, just something to be aware of for your marketing.
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.
It all depends on what somebody is looking for: a sortable data table for presentation, a table (structure) editor, a spreadsheet, a data grid? All these things look very similar, but they require different approaches really.
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 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.
Thanks for your feedback, really appreciate it! I think you're right that the "Reliable" feature might not tell the user much.
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 :-)
Thanks pictur, appreciate your reply! How would I share the developments? I am not really a Twitter user. (You can however subscribe to a mailing list, which you'll find on the bottom of the homepage.)
oh man javascript devs are looking at what winform devs have been getting away with for years...
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.
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!