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.
I don't have a horse in this race - I don't use React Table or render tables in canvas. I still felt compelled to comment because it's not clear you realize that you're being closed-minded and ignoring what littlecranky67 is trying to explain.
Sometimes, no amount of optimization will achieve your performance objectives with the "obvious" path and you quickly find yourself deep in diminishing returns.
Sometimes, you really do have to do an extraordinary amount of work and cover an intimidating minefield of edge cases and heisenbugs to achieve a viable, working solution.
Of course it's almost always better to use a DOM library and just be done. Of course implementing copy+paste and drag-and-drop on Canvas is a masochistic slog. Nobody wants to do this; not even the insane.
The question is whether when the need arises and you've exhausted all other avenues, can you engineer the hard solution?
Sure, and I guess it depends on your performance requirements. As someone who has built a virtual table implementation in the past, I would much rather deal with the performance issues and nitty gritty micro-optimizations than go anywhere near canvas or WebGL for table rendering. But then again, I don't think my standard for acceptable performance was as high as OP's; I wasn't shooting for a buttery smooth 60fps with no jank, but simply trying to get something usable that wasn't frustratingly slow. If you really do need the performance, sure, I concede that maybe canvas/WebGL is the only way to go, but you'd better be damn sure that you really need the performance before you enter that mess.
Also if accessibility is a requirement, you'll have to implement a fallback in DOM, although you're probably no longer optimizing for raw speed in that case.
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.
Google Sheets is not a table, which is what the discussion is about.
Edit: It also is not exactly the poster child of good UX and accessibility (or even performance, for that matter), so I'm not sure it's the best example.
