[OmarIsmail]

Thanks for the detailed answers!

I'm maintaining a web spreadsheet that supports 10s of thousands of rows and have spent a lot of time on optimization. We have to handle some richer content (i.e. contact pictures) so simple spans aren't always sufficient.

The way we're doing the rendering each cell is its own div and we reuse divs as they scroll out of the viewport (changing their top position). Previously I was using innerHTML on each div but I found that constructing the dom nodes manually (document.createTextNode, etc) and then doing a dom.appendChild turned out to he slightly faster (full "wipe" = 16% lower render time). I then cached those prebuilt DOM nodes and then doing a full wipe ended up being 3x faster.

So there was a small speedup on initial scroll and then when you're scrolling around and seeing rows/cells that you've seen before there's a large speedup. Not sure if that's helpful, but maybe worth investigating.

And yes, I know what you mean about scroll events not getting called synchronously. There seems to be a difference in how some browsers handle scrolling vs painting. I actually filed a bug with Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=619796...) as they introduced an issue in Jan 2015 that I just discovered.

And yes, I really don't want to implement custom scrollbars so I'm hoping to get optimized enough to not need them... we'll see though.

[cel1ne]

You don't ever need to add or remove divs when you're not resizing the window. You just need one more than your window is able to display and move the divs up and down with a tiny offset. The other times you can just change their content.

[EGreg]

Why? Can you elaborate?

In our framework, we have an option to yank complex components out of the DOM and replace them with empty containers. And when they scroll back into view, we put them back (and activate them if they are newly rendered).