<table> element is much more complex to process than a <div>. <table> is one of the few elements that actually have a dedicated "Processing model" section in the spec: https://www.w3.org/TR/html52/tabular-data.html#tabular-data-...

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.

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

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

Do you check source on every page you see, or just the ones that feel slow?

> + minimal styling

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.