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

171–180 of 223 posts

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

#171

Post by johangavle »

Gigachad wrote: post #163
johangavle wrote: post #161

Earlier quoted context omitted.

Just guessing here but perhaps they are adhering to some spec about how DOM should work and behave that is as old as the web itself :) HTML standards, JS standards, CSS standards all move forward, perhaps we need a DOM 2.0. Or a new browser that rethinks how it handles DOM to shake things up

Google docs decided to just turn the page in to a big and render everything manually.

Yeah they sure have the resources available to pull such things off. But for the rest of us I dont think it is a way forward at the moment. You really start from scratch and how do you fix accessibility and such. Must have required huge effort on their part

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

#172

Post by WildGreenLeave »

geraldwhen wrote: post #93
ryandrake wrote: post #73

Earlier quoted context omitted.

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

I don't specifically want to include origin in this discussion, but I have never experienced this myself. And I think it might have to do with my (Dutch) culture, or that I am freelance and my clients trust me to do the right thing.

When one of my clients think of something which doesn't work for whatever reason they want me to say no to them. And it doesn't hurt our professional relationship, I will explain them why it is a dumb idea (not in those words of course :-)) and we figure something out that does work properly. They appreciate me being direct and selling them no and they request it themselves.

So while I can understand your comment and I think that it is fair in plenty of situations, it isn't always.

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

#173

Post by alpaca128 »

chrismorgan wrote: post #92
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…

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…

Not only that, but reimplementations tend to have bugs. I cannot remember a single time I used YouTube's comment text field without some bug in the last 5 years. It always breaks in some way, usually when line breaks get involved. Right now when I press Return twice the cursor will only move down one line. It's been like that for at least 6 months. Now and then they replace the bug with a different one, but it never really works correctly.

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

#174

Post by 6510 »

tshaddox wrote: post #131
6510 wrote: post #129

Earlier quoted context omitted.

They look so awesome... wait... neither of them has a working demo at the top of the front page. There is no need to try to talk me into loving something - it wont work. Just show me as many working demos as it takes and show me code. Clearly I'm not the audience. Happy it works for you tho :)

I’m not trying to trick you into liking something and I wasn’t intending to provide demos. They require creating an account because they are serious productivity tools, not cute demos.

Not you. I was referring to the way the sites are structured nowadays. Here, this seems a nice place to demo the dog food?

https://www.airtable.com/integrations

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

#175

Post by rimliu »

lucideer wrote: post #91
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…

Scrolling lists is the first thing that comes to mind when I see someone proclaiming that PWAs will run the world soon, and everything will be based on web tech. iPhone SDK has this from the very beginning. With data sources, delegates, reused cells, etc. It's even easier with SwiftUI (with swipe actions and what not). Yet people are willing to break even simple scroll on the web. Why?

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

#176

Post by 5560675260 »

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.

Standards and browsers are already so bloated, that it's virtually impossible to create a new implementation.

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

#177

Post by Cthulhu_ »

CodeIsTheEnd wrote: post #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.

I really should look into virtualized rendering; turns out I've got some really long lists that are mostly hidden (overflow: hidden I think) that shouldn't be rendered.

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

#178

Post by fleddr »

azangru wrote: post #98
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.

That makes sense. Ideally in that scenario you don't set it at table row level, rather at a higher container level. In this case a container wrapping things far down the page. Your markup structure of course has to support this.

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

#180

Post by Cthulhu_ »

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?

It's easy to underestimate how fast a plain vanilla HTML table can be. It gets a lot more heavy if you start doing things like sorting, column resizing, filtering, and of course it depends on what you have inside of them.

One perf issue I ran into on an older application I'm maintaining was that on render, a callback would iterate over ALL cells to add a drag handle to them, so that a user could change the column width anywhere. That quickly ran a few hundreds of thousands of times.

Post reply on HN