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.<p>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.<p>Grumble grumble
<a href="https://developer.mozilla.org/en-US/docs/Web/CSS/contain" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/CSS/contain</a><p><i>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><p>I wonder how much of this is browser specific because isn't this is all about implementation?
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).<p>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.
I’m not a frontend dev so I just stick to vanilla html and js.<p>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.<p>So what are frontend devs doing that they break all of this so badly? Are they just trying to be too smart, I wonder?
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.
Wow, $2040 for a table component: <a href="https://www.bryntum.com/store/" rel="nofollow">https://www.bryntum.com/store/</a>.<p>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
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.
<a href="https://web.dev/content-visibility/" rel="nofollow">https://web.dev/content-visibility/</a> has a nice blog post about "content-visibility" and "contain".
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 <i>not</i> expect $2040/yr for the JS table library!
Note the related CSS property "content-visibility":<p><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/CSS/content-vis...</a><p>Whereas "contain" prevents recalculations, "content-visibility" doesn't render applicable elements at all until needed.
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:
<a href="https://paste.twilio.design/components/data-grid" rel="nofollow">https://paste.twilio.design/components/data-grid</a><p>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
>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<p>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 :<p>> the entire page is laid out when you scroll the grid.<p>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).
I hope the engineer who works on search console sees this and implements it.<p>Google Search Console is just unusable for browsing large data sets due to this issue.
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.
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.
If anyone is looking for the FASTEST data grid in the world, here is a One Million Cells demo: <a href="https://www.datagridxl.com/demos/one-million-cells" rel="nofollow">https://www.datagridxl.com/demos/one-million-cells</a>.<p>(Disclaimer: I am the maker of the product)