[mattnewton]

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.

[TeMPOraL]

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.

[olifolkerd]

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

[lazyasciiart]

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