Hacker News Reader

Comment by georgewfraser | Hacker News Reader

I have spent way too much time building grid components at my company, and I've found that if you have (1) a lot of data, (2) a dense grid, and (3) a grid that occupies most of the screen, THEN the only way to get 30+fps is to use canvas and do all the layout and drawing logic yourself.

View on HN

Or you can do what google sheets does: only draw N cells at any time, and just change their contents depending on where you are scrolled to.

This is "virtualized" views; other comments in this thread link to some relevant projects!

Google sheets uses canvas. The strategy you describe is orthoganal to canvas versus DOM.

I had to verify this... I cant believe it, they doing all the rendering logic for all the cells in canvas. They are not rendering simple cells either, sheets has may features :O.

Testing would be the easy part, in some cases it would be easier than DOM because you can do image diffs... The harder part is BUILDING IT.

They applied some kind of mixed model in which the entire effort connected with rendering the body of the grid (cells) is being drawn in canvas and the rest of it, including headers, selection and editors, are rendered in a regular way. There is no doubt that Google Sheets keeps almost all of its logic on the back-end side.

Have you tried out react-virtualized [0]? The author has invested a ton of time tweaking things left and right in order to get optimal performance. It's by far the best virtualized grid in JS that I've had the pleasure of using. In addition to that, the React Fiber rewrite should eventually introduce a few new APIs which, as I understand it, should enable further performance improvements. If you scroll really fast it'll flicker white and rendering will lag behind a bit, but it won't cause any jank, so the interface remains at 60FPS. It exposes a good number of params which you can tweak to suit most needs. Personally, I think it's not a big deal, as long as the UI runs smoothly. It takes a few extra ms for the view to catch up if I scroll really fast... But I've had similar the same experience with Apple's Numbers and with browsers trying to render huge HTML tables and it hasn't bothered me.

I've gone back on forth on this topic quite a bit. I used to be a strong believer you should virtualize everything. But then you've broken in-browser search, and you find yourself having to write and support even more code. Using canvas? Say goodbye to accessibility. Now, I'm not saying this is the case for your use-case, but I think that in some cases it's worth seriously reconsidering the design and just going with a simple table that leverages built-in browser functionality and traditional pagination. If you have so much data that you struggle to load and display it with JS, it may be a good idea to take a step back and explore alternative strategies for presenting the data to your users. As an extreme example, a 1 million by 1 million table would probably contain too much data for any consumer to really make sense of it. I only say this because I had a couple experiences where having heard that might've helped keep things simpler. I'll still happily reach for react-virtualized when I find a situation that merits its use.

[0] https://bvaughn.github.io/react-virtualized/#/components/Gri...

canvas would be a pain to have automated test. https://github.com/openfin/fin-hypergrid/issues/540

even with sikulix ?

Maybe that's the compromise for a good user experience?

Reply on news.ycombinator.com