To simplify my question let's assume for a minute that all users are using the latest version of Chrome to view a particular website.

Using the latest libraries (Polymer for example), I can render a VERY large list of constantly changing records in DOM and it will only create enough DOM elements to render what is visible on the screen. Polymer will even render the list on the GPU for me.

I can see that there is alot of investment in canvas based data-grids eg: https://github.com/openfin/fin-hypergrid

My question is - given the above - why, or have I missed the point?

  • Who are these lots of people? Have you asked them why? – GrandmasterB Mar 23 '16 at 17:52
  • @GrandmasterB - sorry, my wording was bad, I have edited my post. – Cheetah Mar 23 '16 at 17:56
  • Have you read the Readme doc on your link? I'm watching this grid in action with all the drag and drop, sorting on the fly, of a large amount of data, so it looks like you'd pretty much have to draw all this stuff. Not sure regular html grids could do all this. – JeffO Mar 23 '16 at 18:10
  • @JeffO - I've not seen anything that couldn't be achieved in DOM. My question is specifically, why go to the extra bother of drawing it on the canvas rather than just letting the browser take care on it. – Cheetah Mar 23 '16 at 18:34
  • 2
    Because the people drawing to canvas aren't going along with your "assume for a minute that all users are using the latest version of Chrome to view a particular website" – LindaJeanne Mar 23 '16 at 20:09

Even if we do assume all browsers supported the features necessary to do all of these things in HTML...

The purpose of this project is to address the Finance/Big Data community's desire for a high performance, unlimited row data-grid

This is simply not something the DOM is designed for.

For some apps like the financial one I work on, rendering a complicated grid with thousands of rows and dozens of columns while also enabling a huge amount of responsive end-user customization is the front-end performance bottleneck.

In particular, row virtualization is absolutely mandatory in these applications. That means only the rows currently visible to the user get rendered, and the other several thousand rows in the grid are completely ignored until the user scrolls them into view. The DOM does not (and I believe it cannot) do this optimization for you; you have to write at least some Javascript no matter what to get reasonable performance. But if you write your own grid renderer using Canvas, it's almost trivial to render only the currently visible subset of rows/columns.

Plus, in a more general sense, if your grid rendering relies solely on Javascript code invoking the Canvas API (as opposed to any details of the DOM rendering algorithm), it's much easier to implement various UI features and optimizations in a way that will work and work efficiently on every browser with basic Canvas support.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.