[TheAceOfHearts]

I recently had a problem where I had to render tables that could have around 750 columns and 40 rows. I tried it with angular and it would cause everything to stop for around 90 seconds (that was the initial version with some poorly written directives inside of it, afterwards I tried making another angular one and it still took around 10~ seconds if I recall correctly).

I rewrote it in React and got the render time down to around 600ms~ Not GREAT, but far more acceptable than a couple seconds. It's worth noting that the react version doesn't do anything fancy, it just has to display the table with some tooltips. (There's a lot of room for improvement, for example, I could only render whatever amount of rows are in view and defer rendering the rest.)

I tried Griddle and, if I'm remembering properly, it took around five seconds to render a 750x40 table. The overhead of all the features they provide made it a suboptimal solution for us :(.

Unfortunately, I don't think you can optimize horizontal scrolling as easily as you can optimize vertical scrolling. I looked around as well and was unable to find a suitable library.

[dengar007]

One of the library authors here -- That sounds like quite the table! I wouldn't doubt that Griddle would have a bit more overhead than the solution you mentioned. I wonder if the performance would be better in this version -- not saying it would necessarily but it may :) We stripped out one of the more complicated parts (the piece that let people specify a callback to obtain external data) to its own component.

Horizontal scrolling definitely sounds like an interesting idea. Seems like it would be feasible to add -- I'll have to think about that a bit more. Also, if the solution you came up with is online anywhere I'd love to see it!

[rch]

I was thinking more like 200M rows and 16M columns (sparse - stored as compressed rows), or perhaps a grid cell for every geohash address. The only solution I know of is part of custom GUI toolkit rendered with LWJGL in a desktop app that handled the former case (crashed the first time - worked fine a week later). Obviously far fewer elements would actually be resident in the client at any given time.

More common is that I just don't know how many columns there will be (or the datatype, optimal width, etc) until the user performs a series of actions and renders a particular view. I've shoehorned a solution into extjs that works (not scrolling, just dynamically defined), but I'm always looking for options.

[edoloughlin]

I was thinking more like 200M rows and 16M columns

I don't think a user would be able to meaningfully navigate a table like that by scrolling it. How would they cognitively track where they are or how to return to interesting parts of the data? IMHO, you should rethink how to display and navigate this data. The user would need sophisticated search/filtering support.

[rch]

It's the same as zooming in and out in a google map - if you zoom out, the server is providing e.g. averaged data. Thinking about trackpad navigation around a map of tiles (sections of a spreadsheet) is probably more relevant than scrolling per se.

A side window let's you navigate at a high level (low res) and zoom in to data-dense areas. Low level / high res navigation in the grid might be used for exploring data from individual sensors, in context with interpolated values.

You can keep the scrollbars from becoming irrelevant by scaling to the size of a logical grid 'neighborhood' of adjacent tiles at the current zoom level.