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

151–160 of 223 posts

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

#151

Post by simion314 »

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…

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 advanced one if you need stuff like resizable columns, re-ordering columns, sort-able columns.

IMO you don't have experienced with this powerfull tookits, your imagination is lacking and you think that shit that existed for so many years is impossible to do. Nah, it can be done but Google and Mozilla are focusing on JS and failling to implement even the most basic customization stuff for native components , they are probably not even aware that things can be done better because their heads are to deep into the web ass and not seen any good Desktop or mobile toolkit in their lives.

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

#152

Post by johangavle »

Twirrim wrote: post #50
hitekker wrote: post #39

Wow, $2040 for a table component: https://www.bryntum.com/store/ . I'd pay that in a heartbeat if it had the API and UI that fits in with the rest of my software. Better an upfront price in dollars for a component that I know will be well-supported by a company than a "free" component that will likely be abandoned or mismanaged by one bored developer

> abandoned or mismanaged by one bored developer I mean.. you're just at risk of the company going under, or getting bored and randomly deprecating something because they don't care about it. Your risk level wouldn't really change all that much.

With a disclaimer for me being employed at Bryntum (and the main author of the Grid component), I still think the chances of getting long term support are better with a paid component from a specialized vendor. Wether you buy Bryntum Grid or AG Grid, there are agreements and such plus the fact that the products are the livelihood of the devs behind them. For the really large vendors though, I guess some of their widgets are to "plug holes" and the mileage may vary...

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

#153

Post by gitgud »

onion2k wrote: post #138
gitgud wrote: post #134

Earlier quoted context omitted.

In my opinion, good applications perform predictably across different browsers, which means they rely on highly available features across all browsers... meaning they don't use things specific to a single browser/device....

What you're arguing for here is what Google did - they didn't implement 'contain', so everyone got the equivalent of the Safari browser experience. If Google had done what I'm suggesting here then users who are on Chrome, Firefox, Edge, etc would have a much better experience. Safari users wouldn't see any difference. Why would you make the user experience for many people worse than it could just because they don't u…

> "they didn't implement 'contain', so everyone got the equivalent of the Safari browser experience."

Not sure that the Google developers knew that feature existed. Most people in this comment thread were unaware of this feature too, seems reasonable that the Google developers might not have been aware either.

> "Everyone should get the best possible experience for their chosen browser, even if that means users get different experiences."

I like that quote. Good websites do give the best experience a device can handle, rather than cater to what the worst devices are capable of.

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

#154

Post by iforgotpassword »

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…

The weird thing is that some things are hilariously complicated in web, but simple in native, and vice versa.

What you described is very easy in eg Qt. You have a bunch of classes representing the table and the contained data, a rendering class etc. that you can extend and override methods easily. Relatively easy, maximum control.

OTOH some years ago (still Qt4 times iirc) I was supposed to add a messaging function to an app that should look like mobile messaging, with those speech bubbles. It was a freaking nightmare to get this past a proof of concept that wouldn't have weird glitches and performance issues if you tried to break it. After two weeks of iterations we just embedded a QWebView and got it working better than ever before within two days, although we felt pretty stupid and defeated for basically pulling in a browser just for that.

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

#155

Post by setr »

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…

> 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 the visible parts of opened apps, but still switch apps quickly

Etc

This isn’t fundamentally oppositional — it’s the most basic rendering optimization you’d apply (basically view culling), before getting into anything fancy

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

#156

Post by lelandfe »

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.

Another protip, Cmd-Shift-P brings up the command palette, where you can just type "Layers" to get there without clicks!

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

#157

Post by dmitriid »

tshaddox wrote: post #53
TeMPOraL wrote: post #51

Earlier quoted context omitted.

> Modern web interfaces can be designed to be user friendly, performant, and good looking. Right. Name three examples that are all this, and still considered "good UX" by webdev standards. > Try marketing a web app Herein lies the real issue. And it predates the web. I recall a piece of documentation of Windows around 3.11 era, where the developers already threw their hands up in the air over realizing that, no matte…

I like https://airtable.com/ , https://linear.app/ , and https://height.app/ . They are all pushing the limits of interactive web apps, not always entirely successfully, but the overall product experience is mostly smooth and polished. I wouldn't really be able to say what it means to be "considered good UX by webdev standards," but I develop for the web and I like these three.

> they are all pushing the limits of interactive web apps

I wonder if you realise that "pushing the limits of interactive web apps" has about as much functionality as Norton Commander/DOS Navigator from the 1990s?

It's a damning fact for the web platform that what is "pushing the limits of interactive web apps" is literally nothing more than tables and lists.

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

#158

Post by dmitriid »

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.

> Layout change occurs when elements are added or removed from DOM or when they change their size

Layout change happens even as you as much as glance at a web page. See e.g. https://csstriggers.com Also things like getting the size or offset of an element would cause a layout recalculation (I don't know if it's still the case).

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

#159

Post by dgb23 »

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

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

With CSS we only have high level control _and_ a predefined data structure that may or may not make sense for specific cases (DOM tree), so each rendering node has to respect _all_ the features, plus _all_ these dependencies are propagated across the whole tree, whether it makes sense or not for a given use case.

If we had more generic, less abstract control, we would not have the same problems. Maybe there is merit in exposing more control to web developers.

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

#160

Post by agent327 »

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…

There is an implicit assumption here that developers have a better understanding of these issues than the rest of the people involved. My experience is that many developers are clueless about UX in general.

Source: I'm a developer, and I work with other developers. On my team I'm the only person who has studied UX design, which resulted in me getting considerable praise for the quality and useability of my user interfaces. At the same time, I have seen my colleagues design interfaces by literally adding controls to a window in the order they implemented the features, starting in the top-left, and moving slowly down the page in a row by row fashion. Well, that's also a strategy...

The real problem is that most designers just like drawing pretty pictures, and are clueless about UX as well. Pushing that to developers is one option, but it's really a separate skillset.

Post reply on HN