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

161–170 of 223 posts

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

#161

Post by johangavle »

dgb23 wrote: post #159
johangavle wrote: post #149

Earlier quoted context omitted.

I have wondered about this countless times... a game can render hundreds of thousands of polygons per frame but DOM cant handle more than a few thousands of elements without lagging. JavaScript has come a long way, wish the rest of it would catch up. If we as devs can virtualize it, surely browser vendors could too

You’re hinting at something interesting there. As someone who‘s in web professionally but has been programming games as a hobby, I have only naive insight into the latter. But from that superficial understanding I assume it has to do with control: In a game you control the rendering/layout logic more specifically. Not every element has to follow all the rules, they need to follow certain rules, scoped to their use ca…

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

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

#162

Post by rasz »

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?

>table with 40k rows

Oh I have one with 6K rows, 300ms to insert into a page if I try to measure, but in reality browser freezes for 3 seconds (1.8s style, 900ms layout, 300ms update tree). Freezing goes away with position: absolute, but it still takes 3 seconds to show up after .appendChild. I tried replacing Table with Flex divs, even worse speed.

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

#163

Post by Gigachad »

johangavle wrote: post #161
dgb23 wrote: post #159

Earlier quoted context omitted.

You’re hinting at something interesting there. As someone who‘s in web professionally but has been programming games as a hobby, I have only naive insight into the latter. But from that superficial understanding I assume it has to do with control: In a game you control the rendering/layout logic more specifically. Not every element has to follow all the rules, they need to follow certain rules, scoped to their use ca…

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.

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

#164

Post by 6510 »

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…

developers are powerful in the job market, highly in-demand, with companies competing for talent.

But you get to pick one and then you are married and she makes all the decisions.

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

#165

Post by trhway »

>The full page contains 38,000+ (!) elements, which is not how you build a fast web app! The obvious thing to do here would be to change to using a data grid with virtualized rendering

more than 20 years ago we worked on a browser and had tests with tens of thousands table rows. That was fun. The 40K elements today should be absolutely no issue ... until of course :

> the entire page is laid out when you scroll the grid.

and that is the root issue here. For the smooth scroll it should be scrolling over already laid out page (or at least laid out well ahead part of the page).

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

#166

Post by WickyNilliams »

fiddlerwoaroof wrote: post #97
danielvaughn wrote: post #65

Earlier quoted context omitted.

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)

Just be careful of the accessibility doing this. You need to apply the correct role attributes at every level so it is understood by assistive technology to be a table.

Screen readers give special treatment to tables to help users understand what is being presented. They also offer special commands to help navigating in a row or columnar fashion.

You lose this all of this if you use non semantic elements. I believe semantics can even be lost if you change the css display property of an actual element. Make sure to test whatever you do!

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

#167

Post by lucideer »

simion314 wrote: post #151
lucideer wrote: post #91

Earlier quoted context omitted.

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…

This was solved, you render the visible items, and a few extra items before and after, then when the user scrolls you never render new items widgets but recycle the existing ones and refresh their state to match. It is super efficient and was solved in many toolkits, I am sure it is done in Flex4. An example from Flex4 is the DataGrid and AdvancedDataGrid. You get a basic component for simple use cases and a very adv…

It has of course been "solved" many times in many toolkits, that wasn't my point.

My point was that each solution is a compromise, and none can ever be one-size-fits-all optimal.

Rendering "a few" items before and after is a heuristic requiring bounds which will produce variable performance impact depending on the content of your list items. It also doesn't account for scroll jumps at all.

Refreshing state is only more efficient than creating/destroying items in some systems and its performance characteristics are again highly dependent on the content of each list item in your application.

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

#168

Post by lucideer »

setr wrote: post #155
lucideer wrote: post #91

Earlier quoted context omitted.

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…

> 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. Isn’t that the constraint of basically any rendering system? The html page itself — I want to only render what’s on screen, but still scroll down quickly video games — I want to render only what’s in sight, but still turn quickly and render appropriately Windows — I want to render t…

It is exactly, and it's a hard problem to generalise.

My point is that rendering a list widget is more complex than other widgets because it's as complex as general full-page rendering / scene rendering

> This isn't fundamentally oppositional — it's the most basic...

It can be both.

View culling is essentially the complexity I'm talking about. View culling is a heuristic, it produces different impacts depending on many variables within the view, as well as the parameters of your cull.

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

#169

Post by lucideer »

dmitriid wrote: post #140
lucideer wrote: post #91

Earlier quoted context omitted.

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…

> These are fundamentally oppositional requirements That have been solved literally everywhere except the web.

This isn't in the slightest bit true. Many UI frameworks provide performant list elements, they are not performant in all cases. Recreating the functionality of those list elements on the web is not the hard problem here: optimising them for your specific application is.

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

#170

Post by johangavle »

WickyNilliams wrote: post #166
fiddlerwoaroof wrote: post #97

Earlier quoted context omitted.

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)

Just be careful of the accessibility doing this. You need to apply the correct role attributes at every level so it is understood by assistive technology to be a table. Screen readers give special treatment to tables to help users understand what is being presented. They also offer special commands to help navigating in a row or columnar fashion. You lose this all of this if you use non semantic elements. I believe s…

Virtualized scrolling for performance reasons also adds another layer of complexity regarding accessibility. Since not all rows of the table/DataGrid are available in DOM
Post reply on HN