It seems standard that all of these JS table libraries are rendering using <div> elements instead of a <table> element. Why? This really irks me. As far as I can tell, all of the features could be implemented using the correct HTML element rather than using <div> to mimic a table.
Let me preface my answer by saying im the chap that built Tabulator
This is because the <table> element introduces a lot of design constraints.
There is a lot of inhernt styling that would have to be overridden if a table element was to be used. it could also mess with the standard behaviour of other table elements that have been generically styled.
Importantly when you start building interactive complex tables there are 100's of different types of elements needed to make the table function correctly that a standard HTML element simple isn't designed to handle, event making the header and the body scroll separately requirements more elements that a standard table can handle and it would invalid HTML to use the tags inside the table that would be needed to achieve it.
Especially when you move into the world of the virtual DOM a standard table element simply wont cut it
With the inclusion of aria tags there are no accessibility issues as screen readers treat them just as any other tables.
For others; your last point is the most important. Semantic HTML gets you pretty far but there will always be an unhandled case. This is a fine use case of ARIA as long as it’s met with sincere concern for accessibility testing.
Appreciate the details. I've done some minor JS-based table controls while using <table>, but I wasn't dealing with thousands of rows so didn't need the virtual DOM. Sounds like that's the biggest obstacle. Nice work on the project!
For the nested markup and styling it sounds like a perfect fit for creating a web component no?
The virtual DOM, while very impressive, isn't necessary as well. Really depends on what problem you are solving there and what level of support you need for browsers. What problem are you solving? Many entries? Minimal cell mutation control?
For Tabulator the virtual DOM is essential. if you try and load 10,000 rows into a table either the browser will slow down and become almost unusable or crash entirely.
For large data sets it makes the table work regardless of the number of rows
What if you just chunk your DOM writes into small batches, and then put them into a queue, which is then consumed within a requestAnimationFrame() handler? A bit of indirection, but not nearly as much as a complete virtual DOM. (I assume this would result in the table "slowly" populating, but the browser and the page should both remain responsive.)
You can can do this but for large data sets it would take ages and doesnt over come the main issue.
Lets say we are working with 10,000 rows
Yes loading that many elements into the DOM is slow and your approach would stop it blocking, however what it dosnt do is stop the sheer number of elements from overloading the DOM.
Most browsers simply cant handle that many elements in the DOM, if you try and scroll a div containing that may elements at best it will be sluggish and at worst it will simply crash the browser. on devices without much memory it is very likely that the whole DOM will freeze up and make the site unusable.
By adding and deleting the elements as they become visible/hidden it keeps the number of elements in the DOM to a minimum, while improving load time and adding only a bit of extra processing to the scroll event, which modern browsers can handle with ease. giving all round the best solution
Ah, I didn't realize that "culling" of non-viewport-visible divs happened within your vDOM implementation. I agree that that would need to happen either way. If the "culling" process was a separate layer, though, it could also be implemented on top of the DOM-queuing process I mentioned.
I did this myself when writing a chat client's infinite history scrollback. Chat messages that aren't on the screen still have a pure-data "event" representation of them loaded, but their DOM representation (virtual or otherwise) is entirely discarded. Rather than the physical DOM nodes for chat-message divs having fixed positions such that they're able to disappear without affecting their peers' layout, I instead just have the chat messages stacked as regular block elements under reflow, with two fixed-size "scroll pad" divs just above and below the viewport "consuming" and "releasing" the vertical height that had been taken up by message divs as they're added and removed. You can have millions of rows "loaded" (in the sense of parsed data sitting in JS memory) for instant access, with not much browser memory usage at all.
Though, even that memory usage was too much (this chat client is supposed to run beside memory-intensive apps like games), so as well, in my setup, nodes that are far enough off the screen can have their parsed "event" representation discarded, and replaced with a single URL representing the serialized "history chunk" that those events came from. When the scroll distance comes close to them, the chunks are reloaded by re-requesting and re-parsing the chunk (which, helpfully, is usually still in the browser cache.)
Author of another library, Handsontable, here. We actually use <table>, but there are many things that are easier with <div>:
- With <div>, you have complete control over the positioning of the cells. With <table>, you delegate the layout to the browser engine.
- <table> has lots of semantic meaning, which makes it slower to render than a <div>, because the browser engine needs to make a sense of it.
- There are differences in how <table>s are rendered in various browsers. This is especially a problem with old browsers such as IE6.
- It is trickier to implement things like floating headers, virtual scrolling with <table>
Still, Handsontable uses <table> because you can overcome these problems if you're motivated enough. The biggest benefit is that <table> gives you enhanced semantics, which are good for Accessibility, SEO or any other form of code processing.
In addition to that, using <table> gives you out-of-the-box Excel file export because .xlsx files (which are basically zipped XML files) support HTML tables.
> <table> has lots of semantic meaning, which makes it slower to render than a <div>, because the browser engine needs to make a sense of it.
I have to ask: is this really slower overall? I didn't try to make an exact 1:1 comparison, but in my experience, all JS-powered table libraries I've seen start choking around a couple hundred elements. With HTML tables + minimal styling, I can dump 10k+ rows with no performance penalty.
It is not neccessarily a bottleneck, as long as your datagrid library uses the browser's ability to render the table. But if you want a custom look and feel, such as overlapping cells, irregular shaped cells, animated cells, it's far better to do it based on <div>s instead of fighting the browser engine.
Don’t know why you are being downvoted- it’s a real technique to render only a subset of elements that fit on ~2 screen lengths and swap them out as the user scrolls for arbitrarily large tables. Just using virtual dom doesn’t magically solve this but it does make doing things like this parlor trick easier IMO.
And yet I can't shake the feeling that this is part of the problem, not the solution. I have never seen a site using vDOM that didn't feel slow. That includes everything using React that I've seen or made. It might be that the performance loss comes from excessive styling and unrelated superfluous JS, but I'd love to see some analysis on the performance overhead of just the vDOM.
vDOMs do carry a fairly significant performance overhead and they are not worth using where there is only a small amount of data to be handled (which is why it can be turned of in Tabulator if not needed) but on modern browsers it isnt really something you should be noticing.
But when you start dealing with large volumes of data they quickly become the only option.
Even a plain html table with say 10 columns will crash out /massively slow down a browser if you load in 100,000 rows of data.
Browsers simply aren't able to process that may elements being added to the DOM.
In the case of Tabulator you can handle many thousands of rows because it only adds the rows you can see to the DOM, removing/adding them as you scroll.
So yes this means there is more processing when you scroll but at the same time you aren't trying to move 100,000 od DOM elements at once which reduces the load on the browser when loading/scrolling.
Depending on the complexity of what you are dealing with there becomes a point where the trade off in processing/memory usage makes it worthwile
I suspect that may be the primary reason, not JS. When you start juggling details that impact a cell, that in turn impacts all the rest of the table, so you can add up with an additive impact based on the number of cells. <divs> still have that, but actually fall under the well-optimized engine for rendering, well, divs (and other straightforward elements that only impact other elements via positioning, not by things like colspan and rowspan)
But this is speculation on my part. I can say that while I appreciate the semantic definition of table and use the tag appropriately in my own work, I never look forward to it because it's always more work than doing so with divs. There is a reason everyone was happy to leave table-based layout behind and it wasn't (just) a desire for semantic purity.
Tabulator uses aria tags to let screen readers and other accessibility tools know how the table is structured so it is still just as accessible as a normal table even with its increased complexity
Just want to say thanks for handsontable. Thanks. It is a great way for my users (scientists who live in Excel) to feel comfortable with the applications we make to help them discover new therapeutics more efficiently.
the problem is it isnt just the table element, it is the thead,tbody,td,th elements as well
Complex interactive tables need a great number of elements to make them run and these wont conform to the standards of using a table (you cant just put a div inside a tbody element) but that is exactly what you would need to to to get a table with a virtual DOM to work correctly.
There are a lot of different styling tweaks that would need to be overriden for each element, some of which arnt consistent across each browser.
Also people have a tendency to put styles on the generic table tab to style tables across the site. if Tabulator was to then be used on the page, it could have any number of unknown CSS properties set on it, so would essentially have to look at overriding all possible style properties.
where as no one generically styles divs or spans and they come with very little built in styling making them the ideal choice for a library that wants to keeps its functionality isolated from the rest of the site
That's what I use at work, I just wrapped it with Vue and did some moderately horrible stuff internally to allow reactive rendering (and by moderately I mean horribly).
Performance is solid, it's easy to work with for ~90% of the times I use it and there are other ways to handle that last 10%.
I probably wouldn't have used datatables on greenfield but the legacy (in every sense) project I inherited already used it so I went with it anyway.
Try it, it doesn't take long to figure out there's no good way to do even basic features without fighting very hard against the built-in behavior of tables. Also, for even just 1000 rows, all browsers still suck at redrawing if any little thing changes, I believe it's because the entire layout of the table has to be recalculated no matter how small the change is.
I'm certainly not an expert (beginning Python programmer who knows very little about Javascript), but I thought it was because divs can be responsive and tables can't be, but I'm prepared to be corrected on that.
I work as a developer in a trade marketing company, our platform have dashboards with different type of charts for our clients to measure different metrics of their business.
The front end requests to the backend each chart on the current dashboad, then the backend, depending of the type of chart, gets the data from the database and passes it to the front who renders it, it could be a pie chart, a bar chart, a table, etc.
We hade 2 or 3 different types of table charts, al using different js based solutions, one of them using bootstrap, i don't remeber the others.
The javascript solutions had responsiveness issues, when you changed the size of the window, or used something that is not Chrome, column headers messed everything up.
One day i decided to end that and added a new type of chart, it expected one table resultset from the db, and once in the front it rendered a traditional <table> with it's content.
We have no more problems with table charts. It works in every browser and every screen resolution.
It was possible to fix the current js tables of course, but is it realy necessary? We have been using tables since forever, and they are just to correct way to display table data on the web.
I think that the homepage for any software library should first and foremost show example code and output. I clicked and scrolled and learned one useful thing for me: "oh good it mentions react!" But a code example is about 90% of what I want to learn about. I probably won't remember this library in six months when I need one.
Thanks for your feedback, There is a working example of Tabulator on the home screen, and clicking the examples link takes you through to over 30 different working examples complete with formatted source code when you click the "view source" button. if you feel you would benefit form a more specific example, i would be happy to update the home page to make things cleared :)
Thanks for responding. I'm on mobile and still don't see any example or a single line of code on the landing page. I'm sure there are examples in one of the big stack of fat button links, but you haven't quite snagged my attention and buy-in with those! :)
Edit: if I switch to desktop view I see a table.
I would suggest having an absolute minimal code + rendering on the front page somewhere. It tells me so much about your library than anything else could!
Yes the version for mobile is much less revealing im afraid, it was tricky to fit everything on the screen so i scaled back the homepage to something simpler.
Actually the documentation and example links are on the first paragraph of the site, just above the table, but i must have removed that whole section from the mobile view to make things fit in better. I will have a look into that now.
FWIW, I didn't have to click too many times to find a very clear code example that explained exactly what this is for. I hope I remember it in six months when I need it.
Looks really interesting! I was evaluating grid/table projects a while ago for use on project where I wanted high performance with big data sets with custom row rendering and it's obviously a nontrivial problem. There's tons of libraries out there, each with their own quirks and endless issues being posted on their bug trackers.
I ended up using https://www.ag-grid.com/ which started charging for features and appears to making good money. Have you considered going this route?
I've had a brief stint pairing this lib with Angular and server-side pagination while also trying to dance around Django's CSRF requirements on a local machine (aka two separate ‘servers’ for Angular and Django). That was a rather mixed experience, Tabulator mostly prefers convention so bending it to fit an opinionated framework like Angular is awkward. IIRC I still had to deal with data requests via Angular and from Tabulator itself. Never managed to put CSS styles for Tabulator in component styles instead of global ones.
Long story short, for Angular there are similar widgets that also happen to be more popular. I didn't end up using them, so can't say for sure, but I imagine they fit more nicely with the framework they were made for.
Also, dunno if anything changed, but six months ago Tabulator could use some fine tuning in regard to UX with pagination: if the table is scrolled to the right, on every filtering or pagination operation the position is reset to zero (but not on the table headers, notably). There's also no support for more interesting filtering like number ranges, so I'd need to whip up widgets for that myself.
And, for some reason, the lib sent two data requests every time filters were changed.
A lot has changed in the last 6 months, Tabulator now has its own react component, and the filter issues have been resolved.
There are also examples of how to build range filters in the example section.
If you have any particular areas of concern feel free to raise an issue on GitHub and they will be resolved.
As for tighter integration with frameworks, in the next release Tabulator will have a reactive data mode, that will allow it to change as data is changed in the column and data arrays, making it simpler that ever to work with the same design paradigm as modern frameworks
Handily, this is exactly the sort of thing I was looking for this morning for use in a project I'm doing (I'm making a library system as a project, and want to have the ability to access and edit the database info directly in the admin part of the app) - but I didn't really know what to search for - I guess this is part of the problem of learning programming is not only working out what you need, but how to ask for it (a similar issue arose previously where I was making a pig's ear of something and it turns out I actually needed to use getattr() and setattr() in Python, but just stumbled across getattr() when looking at something else). Anyway, I'll be able to make a start on that next week now - which is immensely gratifying.
Also, thanks for explaining the implications of the MIT licence simply in the licence area - it's not something that those who are wet behind the ears always find easy.
Thanks for the feedback, yes the licensing terms is something that i often get asked about so thought it would be easier if i could bullet point it out :)
Tabulator has a wide variety of options for handling large data sets. because it uses a virtual DOM you can effectively load as many rows as you like into the table, with the limit being defined by the amount of memory on the browsing machine and loading time to pull in the data.
With the virtual DOM enabled Tabulator will then only render the rows that are visible to the user, creating and destroying them in real time as the user scrolls through the table
I did a huge deep dive on HTML/Javascript table libraries when I started working on Polar - which is a document management platform for PDF and cached HTML content (https://getpolarized.io/)
I didn't actually see Tabulator when I did the full comparison and this seems to be right up there with Tabulator.
Table support is hugely important for us. We have to render the list of PDFs and documents you're managing, sort them, and also not necessarily have to render them all on the same page, so having pagination is insanely important.
There's a few things react-table doesn't do a very good job on including key bindings so I'm going to have to take a look at this library too.
One of the biggest problems with react-table is you end up with 2 headers. There doesn't seem to be a way to get rid of it. Its annoying if you have to fit the table in small space, or if you have just a few rows.
Not sure what you mean. You don't have to have 2 headers with react-table, but you can if you want to. Just look at the example screenshots of tables in the Polar app (the comment to which you replied). The tables have a single header. It's simply a matter of how you structure your `columns` input to the React-table component.
Where do you see 2 headers? It only renders a single header per column unless you do something else, and everything is a customizable set of sub-components that you can switch out. Do you have an example of the double headers?
We've had to implement an internal table library with all of these features using React (and react-virtualized for scrolling). It's interesting and impressive to see such a large piece of UI code written without any library.
By removing the need for 3rd party dependencies it helps reduce the overall size of the package, made it easier to manage the source of the system, made it easier for developers to import and dramatically increased the performance of the table, Tabulator used to be built on jQuery but that was a beast of a library and eventually became a bottle neck harming performance more than it aided development.
Removing the need for dependencies was also a great learning experience to implement a variety of systems that you would usually go straight to another library for.
When there is something bespoke in one of the extensible modules there are the occasional use of library's, such as the xlsx downloader or the sparkline formatter. but i only use these in optional components and keep the core dependency free :)
The project I work on used to rely on a relatively old JS table library. It was fairly well maintained and had a ton of great features. However, we eventually had to replace it with a simpler custom solution based on html tables. Compared to html tables, the JS library had worse performance and didn’t work as well on mobile devices.
Our custom solution is basically just a set of conventions for implementing html tables using a JS rendering library. We also wrote a set of single-purpose modules that can be applied to table-rendering views to provide specific features.
Couldn’t agree more. Many times I find myself put off by some charting or visual library only because of stylistic/aesthetic choices the author(s) made. I think no or minimal style is the best approach. Having the feature to add your own is of course nice to have.
As well as built in themes it comes with extensive documentation on the CSS classes as well as overrideable SASS variables for all themes to make customising as easy as possible, more information can be found in the styling documentation:
http://tabulator.info/docs/4.1/style
It doesn't look like any theme is specified in the JavaScript code on the front page. What theme is being used in the example, and how did it get configured?
That is the site theme, it is a specific theme for the site.
each theme is contained in its own CSS file, you simply include the CSS file for the theme of your choice.
Configuring themes for your table is covered extensively in the documentation along with examples of each theme in use:
http://tabulator.info/docs/4.1/theme
I'm pleased that you removed the jQuery dependency in version 4 and am looking forward to upgrading. Your library allowed me to move a lot of awful server-side code to the browser.
Olifolkerd, I would love to know more about Tabulator's approach to supporting multiple frameworks, please.
What was your overall high level approach, and which technologies did choose to use and avoid? Were some frameworks easier than others to integrate with, or have their unique challenges?
I would like to re-implement my old jQuery pie menus so they support various frameworks like Tabulator does, so I would really benefit from your thoughts and experiences, and any suggestions you have for following in your footsteps.
on the whole the key is to stick to vanilla JS and avoid trying to use to forcible a design paradigm that could conflict with other frameworks.
Removing dependencies on other libraries was key to making it interoperable.
Everything in Tabulator is built to be extensible so where an incompatibility exists it is easy to build a solution for a particular framework.
Tabulator still has one hangup in the way it works, in that it dosnt use reactive data (changing the array you passed into the table, does not automatically update the table, unlike react and view, you have to bind watchers at the moment) but this will be coming in the next release. at which point they should all work harmoniously
The biggest challenge is to ensure that things are drawn correctly at the correct time. Because Tabulator uses a virtual DOM it makes it a since to redraw parts of the table when needed
Tabulator has zero dependencies for its core functionality
If you have the time, writing a virtual DOM can be an excellent lesson in the intricacies of DOM manipulation, learning exactly what order to make calls in to optimize the number of times the DOM is updated and reduce the load on the system.
Though if you are not trying to write a lot of data to the screen they are not worth doing to be fair.
Tabulator needs one because if you try and load 10,000 rows of a table into the DOM at the same time it will freeze up as most browsers cant handle that load, but for simpler UI elements it may not be worth the added complexity.
In the documentation for tabulator there is an "Architecture Concepts" section that has a number of pages that provide a bit of detail about how Tabulator works.
We have been using Tabulator for some time now and are really happy with it. Looking forward to trying out v4. Thanks for all the hard work you've put in Oli :)
I've been looking for something like that. It's not too reassuring to see the documentation not display code correctly (black on black text on Firefox?).
Try to use Wijmo -- https://www.grapecity.com/en/wijmo
Its off the shelf plugin and compatible with raw JS , AngularJS, Angular 2 , React & Vue.
I agree that documentation is not that great but the with few examples you will be ready to go very easily.
AG-Grid has some features that tabulator lacks, like multi-cell editing and cell group selection. (but these features will be coming soon to Tabulator)
AG-Grid focus's on being a fully functional spreadsheet where as tabulator goes more down the route of interactive table.
Tabulator has a publicly visible development roadmap so you can see roughly when new features are going to come online.
There is a new release every month or so, so if there is a feature you feel you need you can create an issue on GitHub to get it added to the roadmap.
Most importantly, Tabulator is FREE even for commercial use!
Ag-Grid lost my business for having a very complex, immovable licensing structure. I'm not sure who pays them but someone must be OK with it since they're still in business. It's a shame because I really like the quality of the code and would gladly pay their asking price if they would have a realistic outlook on educational organizations or startups.
I am VERY excited to start trying to use this instead.
The company I work for pays for Ag-Grid, which makes me sad. Overall I find it has been fairly difficult to work with, and there are a lot of breaking changes when upgrading from older versions. I think we could get away with something like Tabulator for most of our use cases. I'm definitely going to try to sell it to the team
