Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

31–40 of 223 posts

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

#31

Post by sdfaksdfjalj »

lxe wrote: 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 page in question is simply a paginated list. There is one way to do it: Render an html list and style it with CSS. Then fucking leave it alone.

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

#32

Post by FastEatSlow »

xmprt wrote: post #30
FastEatSlow wrote: post #21

Earlier quoted context omitted.

I imagine that it could cause accusations from Apple that Google is trying to take their customers out of the ecosystem, putting a nice cash flow at risk.

It's a bad argument because if someone else makes a better product then they deserve to get more users. Nothing's stopping Apple from implementing those optimizations into Safari. That's the whole reason we have competition. If the government is going to make it so that improving your product makes you liable to lawsuits then no one would ever improve anything.

It's not the government dictating the lawsuits, I was referencing the deal between Apple and Google to have Google as the default search engine on Safari.

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

#33

Post by jeroenhd »

cxcorp wrote: post #11
jaywalk wrote: post #2

I have never heard of the "contain" property before this article. It seems like it can be very useful.

Unfortunately, as is often the case when one learns of a new CSS property or a Web API, the browser support is just not there yet. Safari, for example, doesn't support this at all: https://caniuse.com/mdn-css_properties_contain

I don't think this matter much? It's just a performance optimization, Safari can remain slow while all modern browsers benefit. Unknown CSS values should be ignored so there should be no impact on actual usability.

Seems to me like it's excellent for daily use despite the lack of compatibility of outdated browsers.

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

#34

Post by xboxnolifes »

agent327 wrote: post #13
jaywalk wrote: post #8

Earlier quoted context omitted.

> 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.

Maybe webdevelopers should stop trying to make everything look different from its defaults. It used to be that you could reliably predict what clicking the mouse in a region of the screen would do. It wasn't progress, when webdevelopers threw that out...

Unless browser defaults happen to be the optimal expected behavior for the majority of users, sites will always have an edge by changing them.

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

#35

Post by nawgz »

xmprt wrote: post #27
nawgz wrote: post #23

Earlier quoted context omitted.

I'm not sure what you are asking. You can of course build a trivial use-case with a native feature and have it perform as one would expect from a native HTML element. However, it's not like the UI guys in the article didn't do that and implemented some crazy shit poorly. They just slapped a table on the page, incidentally with 38k elements - sounds a lot like what you did actually, and it lagged the page due to brows…

Usable has many meanings and to me personally, a website that isn't very responsive and lags when you scroll doesn't seem very usable.

Did you read the article and the comment I was replying to? Both basically rendered 40k element HTML s. Difference is, the Google UI lags because it is hampered by browser painting/layout computations taking forever, despite the s in discussion having near-identical complexity, so one can conclude the Google UI bug is more-or-less a bad interaction between the UI's CSS and the browser rendering engine.

So, pray tell, how does parent comment decrying UI developers for supposedly not just rendering HTML tables make any sense in light of this context? It is just sass from someone who likes to rail against UI development, there is no insight

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

#36

Post by shadowgovt »

tdrdt wrote: post #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 m…

Yes, it's extremely browser specific. This property is a rendering hint.

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

#37

Post by arendtio »

eska wrote: post #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?

Doesn't sound like you tested it on a mediocre mobile phone, sounds more like a laptop/desktop.

However, regarding your question: For one thing, many pages are being build for mobile devices first nowadays. So you would not simply push 40k rows but use some kind lazy loading which is a lot harder to build and can easily degrade the desktop experience.

Furthermore, people often use libraries to get rid off the browser differences and if you use too many of them, use them inappropriately or just a few that are not optimized for performance you can easily ruin the performance. In addition, the whole npm ecosystem makes it very easy to load and combine libraries. Often you need only a few functions but if your tree-shaking doesn't work correctly you end up with a lot of code that has to be loaded even if it will never be used.

So frontend development is a messy place and it is easy to fuck up the performance. Even though that should be no excuse for any frontend dev to write crappy code...

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

#38

Post by londons_explore »

ajkjk wrote: post #29
jaywalk wrote: post #2

I have never heard of the "contain" property before this article. It seems like it can be very useful.

Browser support aside, it seems very counterintuitive. https://developer.mozilla.org/en-US/docs/Web/CSS/contain suggests that it can cause pages to render differently, which is very strange, considering that the description implies that it only effects when the browser repaints/re-processes region, and not what the result is.

Browsers give no control over when areas are repainted. If you change a bit of CSS or DOM, it will be repainted in the next frame. There is no way to say 'dont paint this yet'.

The thing the contain property does is ensure that a particular Dom change won't affect pixels outside the element involved, which means the browser won't need to do any extra repainting.

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

#39

Post by hitekker »

Wow, $2040 for a table component: https://www.bryntum.com/store/.

I'd pay that in a heartbeat if it had the API and UI that fits in with the rest of my software. Better an upfront price in dollars for a component that I know will be well-supported by a company than a "free" component that will likely be abandoned or mismanaged by one bored developer

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

#40

Post by Scottopherson »

eska wrote: post #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?

Filtering a list is easy when all the data exists on the client and has no advanced filtering controls.

I'd love to slap an input box above a table and call it done but the product owners and designers that fill my backlog have other ideas.

I'd love to make sure this CSS visibility filtering worked well for screenreaders and other accessibility tools but that ticket was pushed down the backlog in favor of replacing native inputs with custom inputs that better match our branding guidelines.

I'd love to make sure these new custom inputs we cranked out last sprint work well for screenreaders and mobile devices, but we had another marketing lead join the company and now the branding guidelines are changing again.

I'd love to just focus on some HTML and CSS, maybe improve some of the touch support for mobile users, but now the release engineering team wants to have a meeting about micro-frontends?

I'd love to get past the existential crisis I had during that micro-frontends meeting and start working on the UI again, but first I have to debug all these failing Docker containers that's required to run our backend.

Really not sure where I'm going with this comment I'm going to stop now.

Post reply on HN