[HN Gopher] How I made Google's data grid scroll faster with a l...
___________________________________________________________________
How I made Google's data grid scroll faster with a line of CSS
Author : mankz
Score : 130 points
Date : 2021-10-27 20:39 UTC (2 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| hitekker wrote:
| 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
| Twirrim wrote:
| > 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.
| jaywalk wrote:
| I have never heard of the "contain" property before this article.
| It seems like it can be very useful.
| ajkjk wrote:
| Browser support aside, it seems very counterintuitive.
| https://developer.mozilla.org/en-US/docs/Web/CSS/contain
| suggests that it can cause pages to render differently, which
| is very strange, considering that the description implies that
| it only effects _when_ the browser repaints /re-processes
| region, and not what the result is.
| shadowgovt wrote:
| "When" can definitely affect the end result if the page
| elements are arranged such that they break the rules implied
| by the contain logic.
|
| For example, the `paint` rule implies that child elements
| have their renderable pixels completely within the containing
| parent. If the containing parent is moved off screen,
| computation of whether any of its children need to be painted
| is skipped. That will cause the child to vanish if it extends
| outside the parent.
| londons_explore wrote:
| Browsers give no control over when areas are repainted. If
| you change a bit of CSS or DOM, it _will_ be repainted in the
| next frame. There is no way to say 'dont paint this yet'.
|
| The thing the contain property does is ensure that a
| particular Dom change won't affect pixels outside the element
| involved, which means the browser won't _need_ to do any
| extra repainting.
| cxcorp wrote:
| 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
| jaywalk wrote:
| It never surprises me to hear that SafarIE doesn't support
| something.
| onion2k wrote:
| 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 you need them.
|
| In this case it's just a performance hint, so Safari users
| would have the same experience they do now. Everyone else
| would benefit.
| jeroenhd wrote:
| I don't think this matter much? It's just a performance
| optimization, Safari can remain slow while all modern
| browsers benefit. Unknown CSS values should be ignored so
| there should be no impact on actual usability.
|
| Seems to me like it's excellent for daily use despite the
| lack of compatibility of outdated browsers.
| lxe wrote:
| 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, there's always a new and different way to do a
| thing, with either new, or pretty much the same ways for things
| to be broken.
|
| Grumble grumble
| agumonkey wrote:
| There are just a few too many forces at play, the quest for
| dynamic easy to start rules (css) and immense flexibility while
| never having to dig into lower layers causes that. Wait another
| 10 years, and even then..
| madrox wrote:
| If you think that's bad, let me talk to you about backend
| development and the reinvention of CRUD over the same time
| period...
| arendtio wrote:
| > 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 components to applications (react, vue, etc.) have
| their own component formats and logic, so that building
| components that can be used with different libraries is
| difficult. Furthermore, building a good component library is in
| itself a pretty daunting task.
| thrashh wrote:
| 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 money to create
| something fleshed out.
|
| On the other hand, when I look for just a specific component
| (like a drop down or autocomplete textbox), there are
| sometimes very complete but because they are a single
| component, it has its own usage and styling conventions that
| are going to be completely different from some other
| component in my app.
|
| No one has the funding incentive of building a complete
| component toolkit for the web.
| zz865 wrote:
| If only web front ends worked as well as Visual Basic in 1996.
| starik36 wrote:
| 1991
| sdfaksdfjalj wrote:
| There page in question is simply a paginated list. There is one
| way to do it: Render an html list and style it with CSS. Then
| fucking leave it alone.
| jaywalk wrote:
| > 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 <select> 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.
| agent327 wrote:
| 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...
| tshaddox wrote:
| 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 <table> 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, etc. Sure, it's fair to say "too bad, I
| don't care about those features anyway" or "too bad, no one
| gets to use those features on the web until web standards
| and browsers decide to implement them," but I don't think
| that's a useful attitude.
| enlyth wrote:
| This seems to be a constant meme repeated in every single
| thread which dares to mention modern web development.
|
| I don't know if it's because the HN community is dominated
| by backend developers who think UIs are pointless and
| should be generated by code, but it's really annoying.
|
| No, we shouldn't be stuck in a rigid framework of shitty
| premade components with zero customizability.
|
| Modern web interfaces can be designed to be user friendly,
| performant, and good looking.
|
| Try marketing a web app which looks like a Java applet from
| 2003 and let's see how many users you get. As much as so
| many developers hate to admit it, things looking modern,
| polished and well designed is important.
| TeMPOraL wrote:
| > _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 matter how good,
| powerful, integrated and interoperable components they
| design, they can't insist on people using them, because
| marketers gonna market and suits will want their apps to
| be unique and branded and shite.
| tshaddox wrote:
| 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.
| jaywalk wrote:
| I understand what you're getting at, but that ship has long
| since sailed. It's also important to note that changing the
| look of elements doesn't necessarily mean making their
| functionality indecipherable. Bad design will always be
| possible, restrictions to try and stop it are pointless.
| sabellito wrote:
| What do you mean "look different from its defaults" in
| regards to scrolling lists of things?
|
| I'm not sure what you meant with the second and third
| phrases, do they relate to the first point?
| bryanrasmussen wrote:
| entertainment media will always develop the ability to
| arbitrarily control every part of the media presentation,
| and the web has developed into an entertainment medium.
| This is why load time is so important, people will wait
| long times for something they need to do, but will not wait
| to be entertained.
| xboxnolifes wrote:
| Unless browser defaults happen to be the optimal expected
| behavior for the majority of users, sites will always have
| an edge by changing them.
| nawgz wrote:
| You should see what you can do with <summary> and <details>
| these days, no more do your native browser elements have to
| look like complete dog to receive free native device controls
| LudwigNagasena wrote:
| Look at Qt and its styles.
| codedokode wrote:
| 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.
| shadowgovt wrote:
| I'd be willing to bet money that Google has hooked the onScroll
| event and is computing their own top left offset for the
| interior panel instead of just letting native scroll logic take
| care of it.
| thanhhaimai wrote:
| Opinions are my own.
|
| I don't think this is recommended to use internally at Google
| because it's not supported on Safari.
| kevingadd wrote:
| Even if they can't use contain, this is a self-inflicted
| problem - if you look at the screenshot, other elements + a
| drop shadow overlap the content list, which means it can't
| trivially be efficiently scrolled by a compositor, and it's
| quite reasonable for the browser to assume that it can affect
| layout. If it were a properly isolated box in the page without
| overlap with overflow turned on I bet this would have already
| worked properly.
| Twirrim wrote:
| But the fancy graphics! Got to have the fancy graphics! Form
| > Function.
| nicoburns wrote:
| That seems like a bizarre reason not to use it, given that it's
| strictly a performance optimisation, and browsers will simply
| ignore CSS rules they don't understand.
| FastEatSlow wrote:
| I imagine that it could cause accusations from Apple that
| Google is trying to take their customers out of the
| ecosystem, putting a nice cash flow at risk.
| xmprt wrote:
| It's a bad argument because if someone else makes a better
| product then they deserve to get more users. Nothing's
| stopping Apple from implementing those optimizations into
| Safari. That's the whole reason we have competition. If the
| government is going to make it so that improving your
| product makes you liable to lawsuits then no one would ever
| improve anything.
| FastEatSlow wrote:
| It's not the government dictating the lawsuits, I was
| referencing the deal between Apple and Google to have
| Google as the default search engine on Safari.
| tdrdt wrote:
| https://developer.mozilla.org/en-US/docs/Web/CSS/contain
|
| _The contain CSS property allows an author to indicate that an
| element and its contents are, as much as possible, independent of
| the rest of the document tree. This allows the browser to
| recalculate layout, style, paint, size, or any combination of
| them for a limited area of the DOM and not the entire page,
| leading to obvious performance benefits._
|
| I wonder how much of this is browser specific because isn't this
| is all about implementation?
| shadowgovt wrote:
| Yes, it's extremely browser specific. This property is a
| rendering hint.
| CodeIsTheEnd wrote:
| 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.
| eska wrote:
| 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?
| Scottopherson wrote:
| Filtering a list is easy when all the data exists on the client
| and has no advanced filtering controls.
|
| I'd love to slap an input box above a table and call it done
| but the product owners and designers that fill my backlog have
| other ideas.
|
| I'd love to make sure this CSS visibility filtering worked well
| for screenreaders and other accessibility tools but that ticket
| was pushed down the backlog in favor of replacing native inputs
| with custom inputs that better match our branding guidelines.
|
| I'd love to make sure these new custom inputs we cranked out
| last sprint work well for screenreaders and mobile devices, but
| we had another marketing lead join the company and now the
| branding guidelines are changing again.
|
| I'd love to just focus on some HTML and CSS, maybe improve some
| of the touch support for mobile users, but now the release
| engineering team wants to have a meeting about micro-frontends?
|
| Really not sure where I'm going with this comment I'm going to
| stop now.
| sgarman wrote:
| Where you are going is that software often the result of a
| complex blend of different stake holders and requirements.
| FastEatSlow wrote:
| They just all need to have the latest shiny thing, spurred on
| by the idea that a huge amount of abstraction is a good thing.
|
| Abstraction is great, our modern world wouldn't exist without
| them, but it's a website.
|
| Let's put our tinfoil hats on, and use this to discover that
| managers promote inefficient development to force higher
| management to put more funding into projects. It's clear now,
| the bloated hobby websites are just from that idea spreading.
| nawgz wrote:
| I'm not sure what you are asking. You can of course build a
| trivial use-case with a native feature and have it perform as
| one would expect from a native HTML element.
|
| However, it's not like the UI guys in the article didn't do
| that and implemented some crazy shit poorly. They just slapped
| a table on the page, incidentally with 38k elements - sounds a
| lot like what you did actually, and it lagged the page due to
| browser painting/layout issues.
|
| Now, finally: how exactly is what you did not just the same as
| this, except they were actually making a usable front-end so
| the addition of CSS broke the browser rendering engine? Because
| it sure doesn't sound like you would know what to do in the
| situation the article discusses...
| xmprt wrote:
| Usable has many meanings and to me personally, a website that
| isn't very responsive and lags when you scroll doesn't seem
| very usable.
| nawgz wrote:
| Did you read the article and the comment I was replying to?
| Both basically rendered 40k element HTML <table>s.
| Difference is, the Google UI lags because it is hampered by
| browser painting/layout computations taking forever,
| despite the <table>s in discussion having near-identical
| complexity, so one can conclude the Google UI bug is more-
| or-less a bad interaction between the UI's CSS and the
| browser rendering engine.
|
| So, pray tell, how does parent comment decrying UI
| developers for supposedly not just rendering HTML tables
| make any sense in light of this context? It is just sass
| from someone who likes to rail against UI development,
| there is no insight
| xmprt wrote:
| I had similar fears when implementing a large table with some
| data visualization during one of my first forays into web
| development. I had noticed how slow things with 100 elements
| were let alone 1000. When I wrote my code that handled much
| more than that, I was surprised how responsive it was. How does
| a company with thousands of employees manage to make something
| that runs more poorly than something I wrote in an afternoon?
| sabellito wrote:
| Assuming you're arguing in good faith, managing complexity of
| large applications requires "something". What something is
| takes many different shapes, some of them trade performance for
| complexity management.
|
| Having said that, it just looks like you're arguing about
| something you don't know much about, while at the same time
| trying to put down people who have been doing this for a while.
| dan-robertson wrote:
| I think this is actually a little subtle: if you don't have
| fixed-width columns then changing the visibility (or more
| strictly the display property) of rows can require column
| widths to be recalculated which is often pretty slow. It's easy
| to say that obviously you should just set fixed widths but it
| is pretty hard to decide what they should be in practice if you
| want the page to still work when someone resizes their window.
| arendtio wrote:
| 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 differences and if you use too many of them, use them
| inappropriately or just a few that are not optimized for
| performance you can easily ruin the performance. In addition,
| the whole npm ecosystem makes it very easy to load and combine
| libraries. Often you need only a few functions but if your
| tree-shaking doesn't work correctly you end up with a lot of
| code that has to be loaded even if it will never be used.
|
| So frontend development is a messy place and it is easy to fuck
| up the performance. Even though that should be no excuse for
| any frontend dev to write crappy code...
___________________________________________________________________
(page generated 2021-10-27 23:00 UTC)