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

61–70 of 223 posts

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

#61

Post by da_chicken »

thrashh wrote: post #45
arendtio wrote: post #19

Earlier quoted context omitted.

> There should just be one way to do a scrolling list, implemented natively and left alone. Maybe this one implementation should not be implemented natively? (otherwise you would need a new implementation for every platform) However, I agree with you, that in the web development we are missing a mature component library. Everybody seems to build his own library when he needs one. In addition, the libraries to connect…

I think it’s a funding issue. A lot of desktop GUI toolkits were funded by the people who created the platform themselves so they had every incentive to make it both flexible and consistent. When I look for a web component, the few component libraries that cover several different components are often extremely incomplete. Often they’re just side projects of a company or even an individual. No one is putting in the mo…

I think that's part of it. I also think that, as far as interactive components, virtually nothing on the web has had a shelf life of longer than 3-5 years. Ever.

The lone exception are the base HTML components. I think the last actual change to those was making textarea resizable, and that's kind of a browser override to the spec as much as anything else. Essentially nothing has actually changed in form and UI elements.

That tells me:

1. The web is too obsessed with novelty to ever settle on one thing on their own.

2. The best group to actually establish such a thing is likely W3C, which means it will take 15 years and we'll have thrown two away as poorly considered before it's said and done. And it won't matter unless the changes would eliminate something as obnoxious as Flash.

That is still entirely possible. The web works very well, but it's still a combination of HTML, CSS and Javascript. The one word I can think of that describes the state of the overall design is "asinine".

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

#62

Post by r3trohack3r »

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

I’m not sure this is different than any other medium.

Examples that come immediately to mind: academic journals, vending machines, car dashboards, magazines, credit cards, TV remotes, washing machines, etc.

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

#63

Post by wildrhythms »

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 management and the people in charge of OK'ing these designs have a 'make-it-happen' attitude and nobody really cares about semantic, native feel when they've invested so much into a "design system" that is largely antithetical to that.

Select elements are the bane of my existence. Impossible to style. I am constantly re-implementing a because it has to look a certain way. Just terrible.

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

#64

Post by jatone »

arendtio wrote: post #19
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 should just be one way to do a scrolling list, implemented natively and left alone. Maybe this one implementation should not be implemented natively? (otherwise you would need a new implementation for every platform) However, I agree with you, that in the web development we are missing a mature component library. Everybody seems to build his own library when he needs one. In addition, the libraries to connect…

this is simply because a single implemention doesn't and won't meet all needs. many times you need a simple component that just renders properly, but some people need a11n, others need a bunch of i18n which opens up another can of worms. and did I mention all of these need to integrate with whatever cluster fuck of a system they wrote? and different UX designs / coding designs.

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

#65

Post by danielvaughn »

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…

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.

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

#66

Post by cerved »

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?

did your test consist of other things found on a site such as the one with the Google data grid or did you just slap a table on an empty page? Is the table fixed height? What are the scroll settings?

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

#67

Post by tshaddox »

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.

I’m not sure what you mean though. Just don’t allow anyone to develop their own table component after the first one was developed?

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

#68

Post by wildrhythms »

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.

100% agree. Also consider that tables, uniquely, size to their content. So a cell's width is actually the width of the widest cell in its column; the cell height is the height of the tallest cell in its row. It's a problem with so much hidden complexity, and people who come up with these beautiful table designs genuinely do not understand the hidden challenges of implementing it.

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

#69

Post by vaughan »

arendtio wrote: post #37
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?

Doesn't sound like you tested it on a mediocre mobile phone, sounds more like a laptop/desktop. However, regarding your question: For one thing, many pages are being build for mobile devices first nowadays. So you would not simply push 40k rows but use some kind lazy loading which is a lot harder to build and can easily degrade the desktop experience. Furthermore, people often use libraries to get rid off the browser…

I wonder if pushing 40k rows to mobile is such a bad idea. Phones have tons of space now. HD video streaming pulls tons of data. I guess mediocre mobiles complicate matters. Usually there are other factors making it implausible. Such as not compressing/compacting the data on the server, and not being able to limit large blob data columns, unable to control the parsing of data, and lack of normalized relational caching on the client. Usually it’s a collection of backend and frontend frameworks that complicate all this. I’m feeling more and more we need thick efficient clients.

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

#70

Post by chiefalchemist »

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

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, in a color that's low contrast with the background color (read: even more difficult to read).

Don't blame the developers some of this do push back. Unfortunately, "the creatives" too often have more juice.

Post reply on HN