Live data from Hacker News

How I made Google’s data grid scroll faster with a line of CSS

medium.com

1–10 of 223 posts

Re: How I made Google’s data grid scroll faster with a line of CSS

#3
I've been doing web development for 20 years now. I don't know if it's strictly endemic to web or frontend, but I feel like we're solving the same problems over and over again, using the same low levels of abstraction.

There's no reason for lists to scroll slowly after so many years of scrolling lists. There should just be one way to do a scrolling list, implemented natively and left alone. Yet, in web development, there's always a new and different way to do a thing, with either new, or pretty much the same ways for things to be broken.

Grumble grumble

Re: How I made Google’s data grid scroll faster with a line of CSS

#4
post #3

I've been doing web development for 20 years now. I don't know if it's strictly endemic to web or frontend, but I feel like we're solving the same problems over and over again, using the same low levels of abstraction. There's no reason for lists to scroll slowly after so many years of scrolling lists. There should just be one way to do a scrolling list, implemented natively and left alone. Yet, in web development, t…

There are just a few too many forces at play, the quest for dynamic easy to start rules (css) and immense flexibility while never having to dig into lower layers causes that. Wait another 10 years, and even then..

Re: How I made Google’s data grid scroll faster with a line of CSS

#6
https://developer.mozilla.org/en-US/docs/Web/CSS/contain

The contain CSS property allows an author to indicate that an element and its contents are, as much as possible, independent of the rest of the document tree. This allows the browser to recalculate layout, style, paint, size, or any combination of them for a limited area of the DOM and not the entire page, leading to obvious performance benefits.

I wonder how much of this is browser specific because isn't this is all about implementation?

Re: How I made Google’s data grid scroll faster with a line of CSS

#7

Opinions are my own. I don't think this is recommended to use internally at Google because it's not supported on Safari.

Even if they can't use contain, this is a self-inflicted problem - if you look at the screenshot, other elements + a drop shadow overlap the content list, which means it can't trivially be efficiently scrolled by a compositor, and it's quite reasonable for the browser to assume that it can affect layout. If it were a properly isolated box in the page without overlap with overflow turned on I bet this would have already worked properly.

Re: How I made Google’s data grid scroll faster with a line of CSS

#8
post #3

I've been doing web development for 20 years now. I don't know if it's strictly endemic to web or frontend, but I feel like we're solving the same problems over and over again, using the same low levels of abstraction. There's no reason for lists to scroll slowly after so many years of scrolling lists. There should just be one way to do a scrolling list, implemented natively and left alone. Yet, in web development, t…

> There should just be one way to do a scrolling list, implemented natively and left alone.

I can't even imagine how that would work without turning into something like that can only be minimally styled and has to be (usually poorly) re-implemented to get it to look the way you want it to.

Re: How I made Google’s data grid scroll faster with a line of CSS

#9
TIL: Chrome DevTools Layers tab, accessible by going to to the three-dot menu > More Tools > Layers, which allows you to see things rendered outside of the browser viewing area (among many other things I'm sure).

If you have something that "unmounts" things as they scroll off the screen ("virtualized rendering" as the article calls it, a common feature for data grids), this is great tool for verifying that behavior.

Re: How I made Google’s data grid scroll faster with a line of CSS

#10
I’m not a frontend dev so I just stick to vanilla html and js.

I created a simple table with 40k rows, slapped an input box above it, and had some vanilla js set CSS visibility on all rows depending on whether they matched. This would update live as I was typing (10ms trigger delay). No optimizations.

So what are frontend devs doing that they break all of this so badly? Are they just trying to be too smart, I wonder?

Post reply on HN