How I made Google’s data grid scroll faster with a line of CSS • Hacker News Board

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

#91

Post by lucideer » Thu, Oct 28, 2021, 12:56 AM UTC

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…

While I agree with the sentiment of this comment (there are so many aspects of modern web development that are layers of abstracted complexity to re-invent wheels long-since optimised). However...

scrolling lists are, once one gets to thinking about them in depth, a lot more tricky to implement than they are to use. In fact I can't actually think of a better example of something that seems at first glance simple, but upon closer inspection is riddled with challenges.

It basically comes down to the simple question of: how do I render as little as possible at a time, but also render everything/anything in the list "immediately" or as fast as possible. These are fundamentally oppositional requirements, and no solution, whether arrived at after 20 or 50 years, will ever not be a compromise of some sort between them.

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

#92

Post by chrismorgan » Thu, Oct 28, 2021, 1:00 AM UTC

wildrhythms wrote: post #63

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…

I work in UX, I am constantly being given designs that don't work well with native/semantic elements- a great example is tables. As soon as the table needs some kind of animation, drag-drop behavior, anything like that, I can't use a anymore; or it becomes some frankenstein kafkaesque amalgamation that is impossible to maintain. Does the table really need an animation? (probably not) drag and drop? (probably not) But…

And when you reimplement , it won’t feel native because different platforms have different conventions (e.g. placement of dropdown, click-and-drag behaviour, whether focus is selection, keyboard shortcuts like Tab), and very few implementations try even half-baked user-agent sniffing to try to emulate the platform. And that’s just thinking about desktop platforms; on mobile platforms, the native dropdown behaviour is simply unimplementable.

I would say: if it’s just about the style of the , stubbornly refuse to reimplement it, just do what you can on it with CSS and try no further. If you’re needing different functional behaviour (e.g. adding right-aligned text on each option, or making it intelligently filterable by typing—e.g. an airport picker making “CHC” match “Christchurch”), then yeah, you’ve got to reimplement even though it’ll necessarily be a smidgeon worse in some ways.

makes a very bad primitive.

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

#93

Post by geraldwhen » Thu, Oct 28, 2021, 1:03 AM UTC

ryandrake wrote: post #73

chiefalchemist wrote: post #70

Earlier quoted context omitted.

For the record...the issues you mention were initiated by former print designers, turned wannabe web designers. No one should underestimate the percentage of "web designers" who don't know the difference between a span and a div, or the damage that level of ignorance is doing. FFS, I still see PSDs (which is a silly format for web design) - already approved by clients - with small (read: difficult to read) font sizes…

> Don't blame the developers some of this do push back. Unfortunately, "the creatives" too often have more juice. It's so bizarre how developers are simultaneously considered 1. powerful in the job market, highly in-demand, with companies competing for talent, and 2. totally powerless to push back against dark patterns, privacy invasions, and poor product or design choices. I mean has anyone even tried saying "You kn…

That’s a great way to not get raised or promoted. The text will be grey on grey. We will intentionally break accessibility because reasons.

I’m not paid to care. Caring actually causes problems.

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

#94

Post by beebeepka » Thu, Oct 28, 2021, 1:14 AM UTC

ryandrake wrote: post #73

chiefalchemist wrote: post #70

Earlier quoted context omitted.

For the record...the issues you mention were initiated by former print designers, turned wannabe web designers. No one should underestimate the percentage of "web designers" who don't know the difference between a span and a div, or the damage that level of ignorance is doing. FFS, I still see PSDs (which is a silly format for web design) - already approved by clients - with small (read: difficult to read) font sizes…

> Don't blame the developers some of this do push back. Unfortunately, "the creatives" too often have more juice. It's so bizarre how developers are simultaneously considered 1. powerful in the job market, highly in-demand, with companies competing for talent, and 2. totally powerless to push back against dark patterns, privacy invasions, and poor product or design choices. I mean has anyone even tried saying "You kn…

I feel like such arguments are rarely made in good faith due to mostly elitist attitudes but I'll give it a try.

It's one thing to push against dark patterns, and completely another to constantly fight your design teams. Do you honestly think the developer is making all these design decisions? Lol

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

#95

Post by megous » Thu, Oct 28, 2021, 1:17 AM UTC

shadowgovt wrote: post #42

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.

Dunno. I have a large plain (onscroll is not listened to) table in Chrome, and it does constant re-layouts during scrolling. It looks like Chrome does some optimization where it only paints portion of the table and when you scroll, it will paint the new portion only when you scroll just slow enough (and does re-layout whenever this happens, I guess). Otherwise you see just white space. It causes huge CPU load too.

Firefox does not do this, and has smooth scrolling as a result with little CPU load.

Sometimes some optimizations just don't work out.

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

#96

Post by runarberg » Thu, Oct 28, 2021, 1:20 AM UTC

dimal wrote: post #84

dfabulich wrote: post #77

Earlier quoted context omitted.

What you need is Open UI. The browser vendors are working on it. https://open-ui.org/ > The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as dropdowns, checkboxes, radio buttons, and date/color pickers. > To do that, we'll need to fully specify the component parts, states, and behaviors of the built-in controls, as well as necessary accessibility…

Oh wow. Thanks for pointing this out. I had no idea this was happening. I've wanted it for forever, but I thought browser vendors had always shut down talk with "just don't style native controls" dogma. Good to see it changing to reflect the reality that everyone does it anyway.

For what it’s worth, I’ve had pretty good luck styling checkboxes and radio buttons (e.g. with appearance: none), however I’ve had pretty though luck styling selects. My best shots at custom selects have involved multiple backgrounds, css masks with linear gradients, etc. As for the options list, I’ve never even tried.

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

#97

Post by fiddlerwoaroof » Thu, Oct 28, 2021, 1:26 AM UTC

danielvaughn wrote: post #65

wildrhythms wrote: post #63

Earlier quoted context omitted.

I work in UX, I am constantly being given designs that don't work well with native/semantic elements- a great example is tables. As soon as the table needs some kind of animation, drag-drop behavior, anything like that, I can't use a anymore; or it becomes some frankenstein kafkaesque amalgamation that is impossible to maintain. Does the table really need an animation? (probably not) drag and drop? (probably not) But…

Every time I’m given a table mockup, it’s flexible column widths with a sticky header. It’s damn near impossible even with JavaScript.

You can do this all in CSS, if you’re willing to restyle all the table elements to use grid. I demoed this at my last job, and it worked pretty well. (This has its own trade offs)

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

#98

Post by azangru » Thu, Oct 28, 2021, 1:27 AM UTC

fleddr wrote: post #57

Note the related CSS property "content-visibility": https://developer.mozilla.org/en-US/docs/Web/CSS/content-vis... Whereas "contain" prevents recalculations, "content-visibility" doesn't render applicable elements at all until needed.

I seem to recall reading somewhere that 'content-visibility' has a performance penalty, because the browser effectively sticks intersection observers on the elements marked with content-visibility:auto; so that setting content-visibility:auto on, say, thousands of table rows delays page render. But now I can't find where I saw that.

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

#99

Post by beebeepka » Thu, Oct 28, 2021, 1:32 AM UTC

nitwit005 wrote: post #90

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?

Presumably, almost all of the rows are tagged with "display:none" then? From the timings I did in the past, rendering tables with thousands of rows and a many columns can take whole seconds.

Table rendering/updates used to be all or nothing, so loading big sets meant waiting for the entire thing. Not sure if that is still the case in all browsers

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

#100

Post by otrahuevada » Thu, Oct 28, 2021, 1:32 AM UTC

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?

Hi! Frontend dev here. What we are doing is covering several other industry standard use cases.

I mean, yes. Sometimes, to some degree, you can get away with something like that, but most of the time real clients have complex requirements.

EDIT: Removed most of the substance of my comment. If my astoundingly fragile downvoters can't be arsed to discuss anything of substance, I don't find bringing said substance to the table worth it. Yay community.