7 ms·

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

454 points by mankz 5y ago

trhway 5y ago
>The full page contains 38,000+ (!) elements, which is not how you build a fast web app! The obvious thing to do here would be to change to using a data grid with virtualized rendering more than 20 years ago we worked on a browser and had tests with tens of thousands table rows. That was fun. The 40K elements today should be absolutely no issue ... until of course : > the entire page is laid out when you scroll the grid. and that is the root issue here. For the smooth scroll it should be scrolling over already laid out page (or at least laid out well ahead part of the page).
eccoses 5y ago
Well done - excellent skills.
robbiejs 5y ago
If anyone is looking for the FASTEST data grid in the world, here is a One Million Cells demo: https://www.datagridxl.com/demos/one-million-cells https://www.datagridxl.com/demos/one-million-cells. (Disclaimer: I am the maker of the product)
- manuel_w 5y ago
  Congratulations on your cool project. You mentioned it 8 times in this thread alone. While I wouldn't call your comments spam (they do refer to their individual parents, though), stumbling over the same link so many times while reading one thread does leave a certain weird taste. https://news.ycombinator.com/item?id=29024792 https://news.ycombinator.com/item?id=29024792 https://news.ycombinator.com/item?id=29024825 https://news.ycombinator.com/item?id=29024825 https://news.ycombinator.com/item?id=29024709 https://news.ycombinator.com/item?id=29024709 https://news.ycombinator.com/item?id=29024850 https://news.ycombinator.com/item?id=29024850 https://news.ycombinator.com/item?id=29024739 https://news.ycombinator.com/item?id=29024739 https://news.ycombinator.com/item?id=29024768 https://news.ycombinator.com/item?id=29024768 https://news.ycombinator.com/item?id=29024934 https://news.ycombinator.com/item?id=29024934
FractalHQ 5y ago
Svelte has solved performance, and made writing butter smooth, lightning fast web apps 10x easier with 10x less code. Blows my mind that more companies haven’t adopted it considering devs fall in love with the unmatched DX, and users get highly optimized apps shipped to them at a faster rate thanks to the boost in dev speed.
jaywalk 5y ago
I have never heard of the "contain" property before this article. It seems like it can be very useful.
- ajkjk 5y ago
  Browser support aside, it seems very counterintuitive. https://developer.mozilla.org/en-US/docs/Web/CSS/contain 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.
  - londons_explore 5y ago
    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.
    - extra88 5y ago
      You can say “don’t paint this yet” if it’s not within the viewport. In addition to ‘contain’ there’s also ‘content-visibility’. https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility https://developer.mozilla.org/en-US/docs/Web/CSS/content-vis...
  - shadowgovt 5y ago
    "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.
- 5y ago
lxe 5y ago
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
- tester34 5y ago
  Same things happen on native apps. Let it be Winforms or WPF.
- agumonkey 5y ago
  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..
- jaywalk 5y ago
  > 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.
  - LudwigNagasena 5y ago
    Look at Qt and its styles.
  - agent327 5y ago
    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...
thanhhaimai 5y ago
Opinions are my own. I don't think this is recommended to use internally at Google because it's not supported on Safari.
- kevingadd 5y ago
  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.
  - pcwalton 5y ago
    I don't think this is a reasonable assumption for the browser at all. It's 2021; WebRender has proved that a better design is possible.
    - kevingadd 5y ago
      Sure, but are Chrome and Safari going to do a WebRender-style renderer anytime soon? WebRender is great but in practice it affects at most (generously) 20% of the web audience. Optimize for the browser you have, or maybe the browser coming next year, not the one your customers will have in 5 years.
  - Twirrim 5y ago
    But the fancy graphics! Got to have the fancy graphics! Form > Function.
- nicoburns 5y ago
  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.
  - 5y ago
eska 5y ago
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?
- rasz 5y ago
  >table with 40k rows Oh I have one with 6K rows, 300ms to insert into a page if I try to measure, but in reality browser freezes for 3 seconds (1.8s style, 900ms layout, 300ms update tree). Freezing goes away with position: absolute, but it still takes 3 seconds to show up after .appendChild. I tried replacing Table with Flex divs, even worse speed.
  - robbiejs 5y ago
    If your table is simple (values, no markup), try DataGridXL: here's a One Million Cells Demo that loads in an eyeblink: https://www.datagridxl.com/demos/one-million-cells https://www.datagridxl.com/demos/one-million-cells. (Disclaimer: I am the maker)
    - rasz 5y ago
      Its not real. What good is virtual table if I cant search for contents of last row, "2000;1", after loading the page :( Still, this gives me an idea. Dump contents of my table as text under virtual one so search will at least scroll down to appropriate offsets.
      - robbiejs 5y ago
        Version 2 (december) will have a very fast search feature. But you're right: CTRL+F does not work, as it is virtual. I don't really understand your idea, can you elaborate?
- sabellito 5y ago
codedokode 5y ago
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.
- dmitriid 5y ago
  > 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 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).
- shadowgovt 5y ago
  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.
  - megous 5y ago
    Dunno. I have a large plain (onscroll is not listened to) table in Chrome, and it does constant re-layouts during scrolling. It looks like Chrome does some optimization where it only paints portion of the table and when you scroll, it will paint the new portion only when you scroll just slow enough (and does re-layout whenever this happens, I guess). Otherwise you see just white space. It causes huge CPU load too. Firefox does not do this, and has smooth scrolling as a result with little CPU load. Sometimes some optimizations just don't work out.
fleddr 5y ago
Note the related CSS property "content-visibility": https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility https://developer.mozilla.org/en-US/docs/Web/CSS/content-vis... Whereas "contain" prevents recalculations, "content-visibility" doesn't render applicable elements at all until needed.
- azangru 5y ago
  I seem to recall reading somewhere that 'content-visibility' has a performance penalty, because the browser effectively sticks intersection observers on the elements marked with content-visibility:auto; so that setting content-visibility:auto on, say, thousands of table rows delays page render. But now I can't find where I saw that.
  - fleddr 5y ago
    That makes sense. Ideally in that scenario you don't set it at table row level, rather at a higher container level. In this case a container wrapping things far down the page. Your markup structure of course has to support this.
DigitalSea 5y ago
What makes this even more ironic, is that for a period of time, Chrome was one of the only browsers to support the contain property. I've been using this property for years to speed up my applications, it does have quirks (especially using strict), but reading up on the different modes it can offer huge performance gains for large apps.
joshspankit 5y ago
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!
- mankz 5y ago
  Not per year! The EUL license is USD 680/developer and is *perpetual* + support & upgrades are optional.
  - jackdh 5y ago
    Also missing a few power features such as advanced pivoting and row grouping which is a shame.
    - mankz 5y ago
      Grouping of headers + rows supported. https://bryntum.com/examples/grid/grouping/ https://bryntum.com/examples/grid/grouping/ Pivot on the way, ETA Q1/Q2 2022 Would love to hear any additional features you feel should be present in a full fledged grid package.
atum47 5y ago
Just to be clear, Google console is a nightmare in terms of ui/ux. I had to use it a lot when publishing my games or creating ads for them.
TheSisb2 5y ago
Shameless plug: we had a really hard time finding an accessible data grid that matches the specs, so we built one recently (in React) for our design system. It’s very minimal but completely composable. For example we don’t have virtualized rows or frozen columns but that’s something that can be added on later; we focused on a foundationally accessible data grid to start: https://paste.twilio.design/components/data-grid https://paste.twilio.design/components/data-grid I hope that other data grid libraries can mimic some of this to improve web accessibility. These components can be really tedious to interact with today
b20000 5y ago
hey, at least those googlers all passed leetcode.
- machiaweliczny 5y ago
  Ironic. Actually I got offer from google and virtualised table was part of interview. Refused as they use own weird frameworks and job was boring.
tdrdt 5y ago
https://developer.mozilla.org/en-US/docs/Web/CSS/contain 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 5y ago
  Yes, it's extremely browser specific. This property is a rendering hint.
CodeIsTheEnd 5y ago
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.
- lelandfe 5y ago
  Another protip, Cmd-Shift-P brings up the command palette, where you can just type "Layers" to get there without clicks!
- Cthulhu_ 5y ago
  I really should look into virtualized rendering; turns out I've got some really long lists that are mostly hidden (overflow: hidden I think) that shouldn't be rendered.
hitekker 5y ago
Wow, $2040 for a table component: https://www.bryntum.com/store/ 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
- s-lambert 5y ago
  The cost doesn't seem that different from ag-grid[0] (which is also fairly popular) and costs like $750 per developer per year. https://www.ag-grid.com/license-pricing.php https://www.ag-grid.com/license-pricing.php
- Twirrim 5y ago
  > 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.
  - johangavle 5y ago
    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...
onox 5y ago
https://web.dev/content-visibility/ https://web.dev/content-visibility/ has a nice blog post about "content-visibility" and "contain".
hayksaakian 5y ago
I hope the engineer who works on search console sees this and implements it. Google Search Console is just unusable for browsing large data sets due to this issue.
anonygler 5y ago
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.
- reilly3000 5y ago
  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…
  - capableweb 5y ago
    The Google-Web is even worse on Firefox. My i7-7700K + RTX 2080ti can barely handle rendering some (small/medium) spreadsheets in Google Sheets anymore. It used to work fine, but seems every month the performance of Google properties on Firefox are getting worse and worse. Even YouTube seems to have a artificial delay in starting the videos if you're using Firefox.
throwawayswede 5y ago
Your daily reminder to not publish on stupid Medium.

454 points by mankz 5y ago

>The full page contains 38,000+ (!) elements, which is not how you build a fast web app! The obvious thing to do here would be to change to using a data grid with virtualized rendering more than 20 years ago we worked on a browser and had tests with tens of thousands table rows. That was fun. The 40K elements today should be absolutely no issue ... until of course : > the entire page is laid out when you scroll the grid. and that is the root issue here. For the smooth scroll it should be scrolling over already laid out page (or at least laid out well ahead part of the page).

eccoses 5y ago

Well done - excellent skills.

robbiejs 5y ago

If anyone is looking for the FASTEST data grid in the world, here is a One Million Cells demo: https://www.datagridxl.com/demos/one-million-cells https://www.datagridxl.com/demos/one-million-cells. (Disclaimer: I am the maker of the product)

manuel_w 5y ago
Congratulations on your cool project. You mentioned it 8 times in this thread alone. While I wouldn't call your comments spam (they do refer to their individual parents, though), stumbling over the same link so many times while reading one thread does leave a certain weird taste. https://news.ycombinator.com/item?id=29024792 https://news.ycombinator.com/item?id=29024792 https://news.ycombinator.com/item?id=29024825 https://news.ycombinator.com/item?id=29024825 https://news.ycombinator.com/item?id=29024709 https://news.ycombinator.com/item?id=29024709 https://news.ycombinator.com/item?id=29024850 https://news.ycombinator.com/item?id=29024850 https://news.ycombinator.com/item?id=29024739 https://news.ycombinator.com/item?id=29024739 https://news.ycombinator.com/item?id=29024768 https://news.ycombinator.com/item?id=29024768 https://news.ycombinator.com/item?id=29024934 https://news.ycombinator.com/item?id=29024934

FractalHQ 5y ago

Svelte has solved performance, and made writing butter smooth, lightning fast web apps 10x easier with 10x less code. Blows my mind that more companies haven’t adopted it considering devs fall in love with the unmatched DX, and users get highly optimized apps shipped to them at a faster rate thanks to the boost in dev speed.

jaywalk 5y ago

I have never heard of the "contain" property before this article. It seems like it can be very useful.

ajkjk 5y ago
Browser support aside, it seems very counterintuitive. https://developer.mozilla.org/en-US/docs/Web/CSS/contain 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.
- londons_explore 5y ago
  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.
  - extra88 5y ago
    You can say “don’t paint this yet” if it’s not within the viewport. In addition to ‘contain’ there’s also ‘content-visibility’. https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility https://developer.mozilla.org/en-US/docs/Web/CSS/content-vis...
- shadowgovt 5y ago
  "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.
5y ago

lxe 5y ago

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

tester34 5y ago
Same things happen on native apps. Let it be Winforms or WPF.
agumonkey 5y ago
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..
jaywalk 5y ago
> 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.
- LudwigNagasena 5y ago
  Look at Qt and its styles.
- agent327 5y ago
  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...

thanhhaimai 5y ago

Opinions are my own. I don't think this is recommended to use internally at Google because it's not supported on Safari.

kevingadd 5y ago
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.
- pcwalton 5y ago
  I don't think this is a reasonable assumption for the browser at all. It's 2021; WebRender has proved that a better design is possible.
  - kevingadd 5y ago
    Sure, but are Chrome and Safari going to do a WebRender-style renderer anytime soon? WebRender is great but in practice it affects at most (generously) 20% of the web audience. Optimize for the browser you have, or maybe the browser coming next year, not the one your customers will have in 5 years.
- Twirrim 5y ago
  But the fancy graphics! Got to have the fancy graphics! Form > Function.
nicoburns 5y ago
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.
- 5y ago

eska 5y ago

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?

rasz 5y ago
>table with 40k rows Oh I have one with 6K rows, 300ms to insert into a page if I try to measure, but in reality browser freezes for 3 seconds (1.8s style, 900ms layout, 300ms update tree). Freezing goes away with position: absolute, but it still takes 3 seconds to show up after .appendChild. I tried replacing Table with Flex divs, even worse speed.
- robbiejs 5y ago
  If your table is simple (values, no markup), try DataGridXL: here's a One Million Cells Demo that loads in an eyeblink: https://www.datagridxl.com/demos/one-million-cells https://www.datagridxl.com/demos/one-million-cells. (Disclaimer: I am the maker)
  - rasz 5y ago
    Its not real. What good is virtual table if I cant search for contents of last row, "2000;1", after loading the page :( Still, this gives me an idea. Dump contents of my table as text under virtual one so search will at least scroll down to appropriate offsets.
    - robbiejs 5y ago
      Version 2 (december) will have a very fast search feature. But you're right: CTRL+F does not work, as it is virtual. I don't really understand your idea, can you elaborate?
sabellito 5y ago

codedokode 5y ago

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.

dmitriid 5y ago
> 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 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).
shadowgovt 5y ago
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.
- megous 5y ago
  Dunno. I have a large plain (onscroll is not listened to) table in Chrome, and it does constant re-layouts during scrolling. It looks like Chrome does some optimization where it only paints portion of the table and when you scroll, it will paint the new portion only when you scroll just slow enough (and does re-layout whenever this happens, I guess). Otherwise you see just white space. It causes huge CPU load too. Firefox does not do this, and has smooth scrolling as a result with little CPU load. Sometimes some optimizations just don't work out.

fleddr 5y ago

Note the related CSS property "content-visibility": https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility https://developer.mozilla.org/en-US/docs/Web/CSS/content-vis... Whereas "contain" prevents recalculations, "content-visibility" doesn't render applicable elements at all until needed.

azangru 5y ago
I seem to recall reading somewhere that 'content-visibility' has a performance penalty, because the browser effectively sticks intersection observers on the elements marked with content-visibility:auto; so that setting content-visibility:auto on, say, thousands of table rows delays page render. But now I can't find where I saw that.
- fleddr 5y ago
  That makes sense. Ideally in that scenario you don't set it at table row level, rather at a higher container level. In this case a container wrapping things far down the page. Your markup structure of course has to support this.

DigitalSea 5y ago

What makes this even more ironic, is that for a period of time, Chrome was one of the only browsers to support the contain property. I've been using this property for years to speed up my applications, it does have quirks (especially using strict), but reading up on the different modes it can offer huge performance gains for large apps.

joshspankit 5y ago

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!

mankz 5y ago
Not per year! The EUL license is USD 680/developer and is *perpetual* + support & upgrades are optional.
- jackdh 5y ago
  Also missing a few power features such as advanced pivoting and row grouping which is a shame.
  - mankz 5y ago
    Grouping of headers + rows supported. https://bryntum.com/examples/grid/grouping/ https://bryntum.com/examples/grid/grouping/ Pivot on the way, ETA Q1/Q2 2022 Would love to hear any additional features you feel should be present in a full fledged grid package.

atum47 5y ago

Just to be clear, Google console is a nightmare in terms of ui/ux. I had to use it a lot when publishing my games or creating ads for them.

TheSisb2 5y ago

Shameless plug: we had a really hard time finding an accessible data grid that matches the specs, so we built one recently (in React) for our design system. It’s very minimal but completely composable. For example we don’t have virtualized rows or frozen columns but that’s something that can be added on later; we focused on a foundationally accessible data grid to start: https://paste.twilio.design/components/data-grid https://paste.twilio.design/components/data-grid I hope that other data grid libraries can mimic some of this to improve web accessibility. These components can be really tedious to interact with today

b20000 5y ago

hey, at least those googlers all passed leetcode.

machiaweliczny 5y ago
Ironic. Actually I got offer from google and virtualised table was part of interview. Refused as they use own weird frameworks and job was boring.

tdrdt 5y ago

https://developer.mozilla.org/en-US/docs/Web/CSS/contain 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 5y ago
Yes, it's extremely browser specific. This property is a rendering hint.

CodeIsTheEnd 5y ago

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.

lelandfe 5y ago
Another protip, Cmd-Shift-P brings up the command palette, where you can just type "Layers" to get there without clicks!
Cthulhu_ 5y ago
I really should look into virtualized rendering; turns out I've got some really long lists that are mostly hidden (overflow: hidden I think) that shouldn't be rendered.

hitekker 5y ago

Wow, $2040 for a table component: https://www.bryntum.com/store/ 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

s-lambert 5y ago
The cost doesn't seem that different from ag-grid[0] (which is also fairly popular) and costs like $750 per developer per year. https://www.ag-grid.com/license-pricing.php https://www.ag-grid.com/license-pricing.php
Twirrim 5y ago
> 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.
- johangavle 5y ago
  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...

onox 5y ago

https://web.dev/content-visibility/ https://web.dev/content-visibility/ has a nice blog post about "content-visibility" and "contain".

hayksaakian 5y ago

I hope the engineer who works on search console sees this and implements it. Google Search Console is just unusable for browsing large data sets due to this issue.

anonygler 5y ago

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.

reilly3000 5y ago
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…
- capableweb 5y ago
  The Google-Web is even worse on Firefox. My i7-7700K + RTX 2080ti can barely handle rendering some (small/medium) spreadsheets in Google Sheets anymore. It used to work fine, but seems every month the performance of Google properties on Firefox are getting worse and worse. Even YouTube seems to have a artificial delay in starting the videos if you're using Firefox.

throwawayswede 5y ago

Your daily reminder to not publish on stupid Medium.