I think that's only scary to folks like you and me, sadly.

How can those of us working in performance make the case that someone should improve performance on their site, if the tools I use to show them that are even worse?

The logged-in version uses over 20MB of resources, 17 of which are JS. It loads react, moment, lodash, and some of the other usual suspects, and all of this runs before anything useful is shown.

It depends. Coming from a performance focus, I'd say that if browsers were to all reliably support progressive decoding and rendering, that would be the biggest one. Better than thumbnail hacks, with no extra work!

If not, then thinking of photography, large image support would be it.

It's a great format to convert any static image to, with no real limitations:
- Efficient lossy compression
- Alpha channels
- Wide colour gamut
- Large image support (> 4K), which is important for photography sites
- (Nice to have) Progressive decode

Other formats fail at one or more of the above.

So *that's* why all of a sudden the dialog shifted to optimising browsers for frameworks, instead of optimising frameworks for browsers. Utter nonsense.

Hey Paul! 👋

I'm in the market for pretty much the same. There's a few coming later this year that I'm waiting for, namely the ASUS PA32QCV, and the LG 32U990A.

Proposal filed! github.com/web-platform...

Would something like Temporal meet the criteria for well-defined and well-tested?

The closest I can think of is a ponyfill, but that’s generally only used for JS implementations that avoid touching any globals: github.com/sindresorhus...

Although perhaps the idea could be generalised to encompass CSS as well?

I’m so tired of hearing “the DOM is slow”…

I’ve been doing performance for a while, and I’ve yet to find a single case where reading or writing to the DOM was a legitimate bottleneck.

Poor timing? Sure. Excessively large DOMs? Sure. But React won’t magically save you from those either.

Sorry buddy, it's official.