Earlier quoted context omitted.
Right, which makes it a deal-breaker for almost all use cases. Plus, I'd guess that it's almost always less effort to optimize the DOM-based approach than to (poorly) reimplement all of that browser functionality in canvas.
> it's almost always less effort to optimize the DOM-based approach I remember browsers starting to not love dynamic tables with just some thousands of rows.
If you use a virtual table and only render the content that is visible at any given time, the number of rows ceases to be a bottleneck for rendering. Filtering/sorting becomes the new bottleneck, but you can generally optimize that via specialized indexes/views and other techniques, depending on the shape of your data and your business requirements.
Source: I built a virtual table implementation a decade ago that scaled just fine to tens of thousands of rows, and browsers were a lot slower back then. But my requirements were also relatively simple, so YMMV.