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

41–50 of 223 posts

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

#41

Post by shadowgovt »

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.

"When" can definitely affect the end result if the page elements are arranged such that they break the rules implied by the contain logic.

For example, the `paint` rule implies that child elements have their renderable pixels completely within the containing parent. If the containing parent is moved off screen, computation of whether any of its children need to be painted is skipped. That will cause the child to vanish if it extends outside the parent.

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

#42

Post by shadowgovt »

codedokode wrote: post #16

The article still doesn't answer how scrolling a page can cause layout change. Layout change occurs when elements are added or removed from DOM or when they change their size. I assume there is some Javascript that updates styles on scroll event.

I'd be willing to bet money that Google has hooked the onScroll event and is computing their own top left offset for the interior panel instead of just letting native scroll logic take care of it.

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

#43

Post by zz865 »

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…

If only web front ends worked as well as Visual Basic in 1996.

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

#44

Post by sgarman »

Scottopherson wrote: post #40
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 n…

Where you are going is that software often the result of a complex blend of different stake holders and requirements.

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

#45

Post by thrashh »

arendtio wrote: post #19
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 should just be one way to do a scrolling list, implemented natively and left alone. Maybe this one implementation should not be implemented natively? (otherwise you would need a new implementation for every platform) However, I agree with you, that in the web development we are missing a mature component library. Everybody seems to build his own library when he needs one. In addition, the libraries to connect…

I think it’s a funding issue.

A lot of desktop GUI toolkits were funded by the people who created the platform themselves so they had every incentive to make it both flexible and consistent.

When I look for a web component, the few component libraries that cover several different components are often extremely incomplete. Often they’re just side projects of a company or even an individual. No one is putting in the money to create something fleshed out.

On the other hand, when I look for just a specific component (like a drop down or autocomplete textbox), there are sometimes very complete but because they are a single component, it has its own usage and styling conventions that are going to be completely different from some other component in my app.

No one has the funding incentive of building a complete component toolkit for the web.

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

#46

Post by tshaddox »

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

It's not always only about custom theming. There is a ton of functionality that is simply lacking in web standards. If you want default behavior, feel free to use an unstyled or minimally styled element. But it's not going to have any live searching or filtering, the ability to handle enormous numbers of rows and columns (as can be done with virtualization in JavaScript), draggable rows and columns, resizable columns, etc. Sure, it's fair to say "too bad, I don't care about those features anyway" or "too bad, no one gets to use those features on the web until web standards and browsers decide to implement them," but I don't think that's a useful attitude.

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

#47

Post by starik36 »

zz865 wrote: post #43
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…

If only web front ends worked as well as Visual Basic in 1996.

1991

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

#48

Post by enlyth »

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

This seems to be a constant meme repeated in every single thread which dares to mention modern web development.

I don't know if it's because the HN community is dominated by backend developers who think UIs are pointless and should be generated by code, but it's really annoying.

No, we shouldn't be stuck in a rigid framework of shitty premade components with zero customizability.

Modern web interfaces can be designed to be user friendly, performant, and good looking.

Try marketing a web app which looks like a Java applet from 2003 and let's see how many users you get. As much as so many developers hate to admit it, things looking modern, polished and well designed is important.

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

#49

Post by Twirrim »

kevingadd wrote: post #7
thanhhaimai wrote: post #5

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 alrea…

But the fancy graphics! Got to have the fancy graphics! Form > Function.

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

#50

Post by Twirrim »

hitekker wrote: post #39

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

> abandoned or mismanaged by one bored developer

I mean.. you're just at risk of the company going under, or getting bored and randomly deprecating something because they don't care about it.

Your risk level wouldn't really change all that much.

Post reply on HN