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

81–90 of 223 posts

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

#81

Post by pojzon »

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…

Its not only in web development but software development as a whole.

Very smart ppl very easly fall for “not invented here” way of thinking and pretty much solve the problems that were solved already like hundred times.

It’s hard to fight that, seems to be our nature. But this is something that probably diffrentiates “great” devs from “just” devs.

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

#82

Post by TOMDM »

arthurcolle wrote: post #79
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…

Mandatory standards xkcd

For todays lucky 10,000 https://xkcd.com/927/

For todays lucky 10,000 concerning the lucky 10,000 https://xkcd.com/1053/

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

#83

Post by notreallyserio »

pojzon wrote: post #81
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…

Its not only in web development but software development as a whole. Very smart ppl very easly fall for “not invented here” way of thinking and pretty much solve the problems that were solved already like hundred times. It’s hard to fight that, seems to be our nature. But this is something that probably diffrentiates “great” devs from “just” devs.

I’ve been “burned” many times by using standard off the shelf solutions to problems. Not because they didn’t work or had security issues but because they didn’t do precisely what a stakeholder expected, down to the pixel. No amount of me saying “nobody will notice if our app works the same as everyone else’s” worked.

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

#84

Post by dimal »

dfabulich wrote: post #77
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…

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.

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

#85

Post by lxe »

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…

Right? Mozilla's XUL had the right idea a the time. I wonder if similar things exist for the modern age?

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

#86

Post by lxe »

sergiotapia wrote: post #56
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 you don't invent new ways to render a list how else will you be able to give a talk and get 500 twitter likes?

You're right... I'm undermining my own job security here.

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

#87

Post by pcwalton »

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…

I don't think this is a reasonable assumption for the browser at all. It's 2021; WebRender has proved that a better design is possible.

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

#89

Post by pwinnski »

nitrogen wrote: post #60
tshaddox wrote: post #46

Earlier quoted context omitted.

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…

So do all those things once, in the browser, and then every table can have them. That's maximally useful.

Define "those things," and then tell me what "those things" would be defined at before, say, live search came along. Because however you would have defined search boxes would not have allowed for the development of live search.

Iteration is what brings us progress that we enjoy, while also bringing with it the headache of reinventing the wheel over and over again. Both go hand in hand.

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

#90

Post by nitwit005 »

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.
Post reply on HN