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

181–190 of 223 posts

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

#181

Post by simion314 »

lucideer wrote: post #167
simion314 wrote: post #151

Earlier quoted context omitted.

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

This not true, it was solved correctly before and nobody would force you to use an AdvancedDataGrid instead of a table or 100+nested divs.

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

YEs it depends but 99% of cases you refresh the string for some Label/Text components and some img src , since you do it with native code it will be much faster then creating new DOM elements or changing a DOM element attribute. Plus hacked-up widgets that are not native are forced to listen to tons of events and run non-native code to detect if they should or not run and what to do when to run.

TLDR the problem was solved, we need good enough widgets like in good toolkits and we can still give people the option to create their own "improved" version with their cool library if they want.

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

#182

Post by necovek »

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.

In an fortunate twist for the unfortunate circumstances, the fact that there's fewer browser rendering engines today means that it's easier to get "all" browsers at the table and agree with a singular direction for things like these: there's simply fewer of them.

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

#184

Post by tester34 »

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…

Same things happen on native apps.

Let it be Winforms or WPF.

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

#185

Post by methyl »

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.

I know it's not great for performance, but to get a sticky header and flexible column widths you can render two tables and contain one of them to show only the header which you can then wrap into a , position absolutely to cover the top of the table and give position: sticky.

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

#186

Post by madeofpalk »

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

I know it's not great for performance, but to get a sticky header and flexible column widths you can render two tables and contain one of them to show only the header which you can then wrap into a , position absolutely to cover the top of the table and give position: sticky.

For sticky headers you can literally just put `position: sticky` on the thead now!

https://codepen.io/chriscoyier/pen/WNpJewq

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

#187

Post by madeofpalk »

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…

Why is drag and drop an unreasonable expectation to have for a table where that makes sense?

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

#188

Post by dmitriid »

lucideer wrote: post #169
dmitriid wrote: post #140

Earlier quoted context omitted.

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

> This isn't in the slightest but true.

It is. I personally used a virtual list with custom rendering in Delphi in early 2000s. It is, for all intents and purposes, a solved problem. That is, solved everywhere else.

> Many UI frameworks provide performant list elements, they are not performant in all cases

Yes. On the web.

> Recreating the functionality of those list elements on the web is not the hard problem here

It is a very hard problem on the web because you don't have any APIs to do this properly: asking for element sizes causes the browser to recalculate the layout, you can't batch-render anything, and a million other things that are readily available, once again, literally everywhere else.

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

#189

Post by madeofpalk »

johangavle wrote: post #149
dmitriid wrote: post #139

Earlier quoted context omitted.

> The parent comment is seeing new wheels being designed for a high speed train and wondering why they are reinventing the wheel when wheels have existed forever. Nope. The parent is seeing reinvention of basic UI capabilities such as a basic table and virtualized scrolling and wondering why they are not available natively

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

There's a difference between the two, right? The browser is not just "rendering polygons" - it's actually laying them out. Position of one affects another.

Have thousands of physics entities in a game interacting with each other and see how it goes. That's why we see things like "millions of falling ducks" as an impressive demo or benchmark for 3D programs/engines.

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

#190

Post by jackdh »

mankz wrote: post #150
joshspankit wrote: post #80

I expected a soft-sell somewhere in this article, and the depth of knowledge had me say “respect. I’ll check out this sell”, but I did not expect $2040/yr for the JS table library!

Not per year! The EUL license is USD 680/developer and is *perpetual* + support & upgrades are optional.

Also missing a few power features such as advanced pivoting and row grouping which is a shame.
Post reply on HN