olifolkerd

The latest 4.8 release comes with a load of great new features including a Horizontal virtual DOM for handling tables with large numbers of column, RTL language support and ESM Module importing.

Tabulator, has most of the features of AG grid and is totally free http://tabulator.info/

That feature will be coming soon :)

It comes with a load of built in themes if you are looking for a shinier look: http://tabulator.info/examples/4.6#theming

Thanks.

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 :)

Thanks. I deliberately avoided 3rd party dependencies to try and make the code base as small as possible.

I use react native wrappers at work and embed webviews that allow components like these to be used.

That being said, having a react-native variant for this is on the long term road map

All features of Tabulator are free including a lot of features AG Grid charges for for commercial licenses

Tabulator is licensed under MIT so is free for all to use, even on commercial projects.

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

Thanks,

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

To reduce loading time you can also:

Paginate data (both of local data and from an ajax source: http://tabulator.info/docs/4.1/page

Progressively load via ajax, both on scroll and timed: http://tabulator.info/docs/4.1/data#ajax-progressive

and also manually handle data retrieval yourself and use the replaceData function to swap out data sets as needed

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

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

I wrote my own,

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.

The virtual DOM details can be found here: http://tabulator.info/docs/4.1/virtual-dom

and some basic lifecycle info can be found here: http://tabulator.info/docs/4.1/lifecycle

Hey Don,

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 comes with 8 built in themes, two of witch use only the most minimal markup for the table to make the columns and rows distinguishable.

It also comes with a number of themes to help match other UI frameworks. See the themeing examples here: http://tabulator.info/examples/4.1#theming

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

Happy to hear i could help :D

Sorry to hear you were having trouble, what browser/device were you using?

There is a whole module that exclusively deals with responsive layout.

You can either choose to hide columns that do not fit, or collapse them into a list.

There are extensive options for configuring which columns react in what order and how things are displayed

Checkout the responsive layout documentation for more info: http://tabulator.info/docs/4.1/layout#responsive

weird, that all lodes fine for me. I will look at adding some fallback styling incase those fail to load for some reason

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

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!

If you are looking for a react component then ngduc has kindly built one for Tabulator. it can be found here: https://github.com/ngduc/react-tabulator

Hey Aasasf,

Thanks for your feedback.

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

This is why you need to use a virtual DOM to prevent the DOM from being filled with elements that consume memory and slow it down

Great to hear! if there are any features you feel it is missing, create an issue on GitHub and we can help you out :)

That does come with a price tag of over $800 dollars for commercial use. Tabulator is completely free :)

If you need any pointers on which classes to use for what just let me know :)