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.
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.
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
- 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.