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

131–140 of 223 posts

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

#131

Post by tshaddox »

6510 wrote: post #129
tshaddox wrote: post #53

Earlier quoted context omitted.

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

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

#132

Post by lmm »

agent327 wrote: post #13
jaywalk wrote: post #8

Earlier quoted context omitted.

> There should just be one way to do a scrolling list, implemented natively and left alone. I can't even imagine how that would work without turning into something like that can only be minimally styled and has to be (usually poorly) re-implemented to get it to look the way you want it to.

Maybe webdevelopers should stop trying to make everything look different from its defaults. It used to be that you could reliably predict what clicking the mouse in a region of the screen would do. It wasn't progress, when webdevelopers threw that out...

Maybe browser vendors should provide defaults that don't suck. The whole existence of Twitter Bootstrap is testament to the fact that browser makers were asleep at the wheel.

Platforms exist to support applications, not the other way around. Applications weren't born wanting to reimplement the native controls, they did it because the native controls are not only uglier but also less usable and hopelessly inconsistent between different platforms.

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

#133

Post by reilly3000 »

anonygler wrote: post #123

That jscontroller= stuff in the DOM is Google’s internal framework called Wiz. Easily one of the worst things I’ve used in my career. It’s like a hyper engineered Backbone.js. Working with it is so tedious that passionate web developers who might fix these perf issues burn out and leave. What’s left are promo-seeking impact farmers who don’t really care about these sorts of things.

Meanwhile daily users of Google web apps on Chrome are prone to slowdowns and crashes all. the. time. When I worked at an ad network and lived in DFP/Ad Manager I had to reboot my Mac twice a day to keep the site even usable. Impact indeed…

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

#134

Post by gitgud »

onion2k wrote: post #22
cxcorp wrote: post #11

Earlier quoted context omitted.

Unfortunately, as is often the case when one learns of a new CSS property or a Web API, the browser support is just not there yet. Safari, for example, doesn't support this at all: https://caniuse.com/mdn-css_properties_contain

Writing good browser based software is about delivering the best possible experience for all users regardless of their browser choice. That doesn't mean withholding beneficial features just because they're not available everywhere. It means writing software to take advantage of every possible benefit that improves the user experience, and detecting browser support where necessary to provide fallbacks and polyfills if…

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

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

#135

Post by skolsuper »

true_religion wrote: post #130
bla3 wrote: post #108

Earlier quoted context omitted.

https://open-ui.org/charter > Most recent revision: April 1, 2020 That doesn't inspire confidence...

Isn't that just the charter which lists their goals? Should their organizational goals change massively in a single year? The charter of most NGOs basically stays static for their entire lifetime.

I think they're referring to the date, April 1 is "April Fool's Day" in many countries. Some companies put out joke press releases on April 1 that are not intended to be taken seriously.

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

#136

Post by onion2k »

surajrmal wrote: post #109
onion2k wrote: post #22

Earlier quoted context omitted.

Writing good browser based software is about delivering the best possible experience for all users regardless of their browser choice. That doesn't mean withholding beneficial features just because they're not available everywhere. It means writing software to take advantage of every possible benefit that improves the user experience, and detecting browser support where necessary to provide fallbacks and polyfills if…

This is how you end up with "the performance sucks if you don't use chrome" complaints though. I imagine Google makes use of optimizations only possible in Chrome quite often making their applications provide sub par experiences on other browsers.

This is how you end up with "the performance sucks if you don't use chrome" complaints though.

Not it isn't. You get that by only testing in Chrome, and not putting the work in for other browser users. If you test in other browsers and the performance sucks then you should work to make it as good as possible in those other browsers as well.

Aiming for the same experience everywhere is how you don't use things like the 'contain' hint because it's not available in Safari, and then everyone gets a slower website because of it.

Don't undermine every user's experience just because one browser is lagging behind.

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

#137

Post by Gigachad »

vaughan wrote: post #59
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 is not one set of static requirements for lists. New UX paradigms are being invented all the time, which actually make things more usable. E.g. Think about Airtable vs Google Sheets. Also consider data sources and data binding. Do you bind a cell, a row, the entire table? How do you handle real-time updates or infinite scrolling. How is styling done? It always feels like we should just standardize the current t…

Tables like you mention, have infinite complexity and requirements. If all you need is the most basic grid, the built in element is fine.

But what happens when you need inline editing, filters, searches, live updating data from a server, keyboard shortcuts, etc.

A single standard element will never handle everyone's use cases. 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.

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

#138

Post by onion2k »

gitgud wrote: post #134
onion2k wrote: post #22

Earlier quoted context omitted.

Writing good browser based software is about delivering the best possible experience for all users regardless of their browser choice. That doesn't mean withholding beneficial features just because they're not available everywhere. It means writing software to take advantage of every possible benefit that improves the user experience, and detecting browser support where necessary to provide fallbacks and polyfills if…

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 use Safari?

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

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

#139

Post by dmitriid »

Gigachad wrote: post #137
vaughan wrote: post #59

Earlier quoted context omitted.

There is not one set of static requirements for lists. New UX paradigms are being invented all the time, which actually make things more usable. E.g. Think about Airtable vs Google Sheets. Also consider data sources and data binding. Do you bind a cell, a row, the entire table? How do you handle real-time updates or infinite scrolling. How is styling done? It always feels like we should just standardize the current t…

Tables like you mention, have infinite complexity and requirements. If all you need is the most basic grid, the built in element is fine. But what happens when you need inline editing, filters, searches, live updating data from a server, keyboard shortcuts, etc. A single standard element will never handle everyone's use cases. The parent comment is seeing new wheels being designed for a high speed train and wondering…

> 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

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

#140

Post by dmitriid »

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…

> These are fundamentally oppositional requirements

That have been solved literally everywhere except the web.

Post reply on HN