I spent a ridiculous amount of time working on optimized table rendering in the early years of my company, and I came to a simple conclusion: if you want to display full-screen tables, with dense data, and scroll around fast, the only option is canvas. "Virtualized" HTML tables are always an order-of-magnitude slower, no matter how much effort you put into optimization.
The fundamental reason why you end up back at canvas is that if you are scrolling a full-screen table fast, even at 30 FPS you are going to have to rerender about half the table on each frame. So "virtualized DOM" doesn't really work; it's all about render speed. And canvas allows you to achieve unbeatable render speeds by specializing your drawing algorithm for your particular scenario.
I'm terribly sorry that you ended up in Canvas land for tables. I built and maintained Chart.js for a while, so I know how hard it can be to work with.
As for React Table, I have never run into a situation where drawing a table to canvas has ever been necessary. I guess I'll consider myself lucky, but I would still love to hear your use-case in a more structured format. Maybe a blog post?
I’ve spent a crazy amount of time at my workplace optimizing the shit out of tables.
Canvas is great, you could even get extra oomph with webgl but those break basic things. You have to spend a lot of time recreating basic things like copy paste.
Dom virtualization gets you pretty fast and very usable tables. 30FPS rendering is quite doable with react and friends. Just gotta ensure the layout paint/cycles are small and you’re compositing as much with the GPU.
Like using translate3d instead of using scrollTop
Basically we need a middle ground primitive, something higher than canvas that still allows drawing text real fast but still has copy paste and usual accessibility features but low level enough to be insanely fast.
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.
Comments
I spent a ridiculous amount of time working on optimized table rendering in the early years of my company, and I came to a simple conclusion: if you want to display full-screen tables, with dense data, and scroll around fast, the only option is canvas. "Virtualized" HTML tables are always an order-of-magnitude slower, no matter how much effort you put into optimization.
The fundamental reason why you end up back at canvas is that if you are scrolling a full-screen table fast, even at 30 FPS you are going to have to rerender about half the table on each frame. So "virtualized DOM" doesn't really work; it's all about render speed. And canvas allows you to achieve unbeatable render speeds by specializing your drawing algorithm for your particular scenario.
I'm terribly sorry that you ended up in Canvas land for tables. I built and maintained Chart.js for a while, so I know how hard it can be to work with.
As for React Table, I have never run into a situation where drawing a table to canvas has ever been necessary. I guess I'll consider myself lucky, but I would still love to hear your use-case in a more structured format. Maybe a blog post?
I’ve spent a crazy amount of time at my workplace optimizing the shit out of tables.
Canvas is great, you could even get extra oomph with webgl but those break basic things. You have to spend a lot of time recreating basic things like copy paste.
Dom virtualization gets you pretty fast and very usable tables. 30FPS rendering is quite doable with react and friends. Just gotta ensure the layout paint/cycles are small and you’re compositing as much with the GPU.
Like using translate3d instead of using scrollTop
Basically we need a middle ground primitive, something higher than canvas that still allows drawing text real fast but still has copy paste and usual accessibility features but low level enough to be insanely fast.
How do you deal with copy, paste, and accessibility issues?
Isn't that what Google does on Google Sheets? I can only imagine the ungodly amount of work to get something like that working.
Google Sheets is pretty slow to be honest. You want fast tables. Look at Bloomberg terminal. They’ve spent eons optimizing tables.
Google sheets doesn’t even do smooth scrolling that really annoys me. Excel 365 online feels so much smoother.
Using canvas also means you can't select text, copy/paste, open links, etc, which is a non-starter in most cases.
Well of course not, you have to implement it yourself - just as everything else when drawing a table into a canvas.
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.
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.
Google Sheets is based on canvas. Works pretty good for me.
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.
Even approaches like React-Window?
https://github.com/bvaughn/react-window
You're aware we have IntersectionObserver now?