Notices by Alex Russell (slightlyoff@toot.cafe), page 2

For the Performance Inequality Gap series, I'm gathering new data points in charts that I'd only talked to in prose in previous years. One of those is the difference between the various market segements looks at by price, with the Flagships clocking the new, unlocked cost of the fastest chip in each line, while the lower-end lines capture the mid-tier and low-end segments from various manufacturers.

The blue line that has never bumped above $375? That's worldwide average selling price.

@dotstdy Yes? Obviously? Caches and associated ARBs aren't free, and in the die shots I've worked through for various generations of Android and iOS SoCs, you can see almost as much ARB space on A-series parts as actual cache circuitry. Shrinks help them too.

These are choices about how often you're going to stall for an eternity, and what else you're going to boot of the die (in Apple's case, the radio that Qualcomm wants to sell).

But that's not relevant to webdevs.

@dotstdy The important thing that web developers need to understand is that expensive phones are rare, and cheap phones are everywhere. And that cheap phones are *much* slower than anything they've used in a long time.

Discussions of relative L1D and L1P sizings per core across different manufacturers (e.g.) isn't useful detail, so I omit it.

@callipygian @lauren "Show more"...oh gods, no. Make it stop.

It feels only fair that browsers should detect when you're reading the news in a native app and bombard you with notifications telling you how much better the web version is as you try to scroll.

It me.

@maphew @dotstdy And it doesn't even work! I sit with *so many* teams that are beached on the shores of unshippability because their "move fast" stacks only provided a one-time burst of acceleration, rather than sustainable gains in velocity and momentum.

Adding the time folks have to spend remediating these made-up problems to the cost side of the equation makes these "move fast" systems look like what they are: irresponsibily marketed tools for experts in the hands of n00bs.

I've come to understand what's happening in frontend's decade-long failure to deliver decent user experiences as a sort of epistemic closure. I'm calling it "frameworkism", and the epicenter is now React.

Here's a lot of words on why we should all reject it, and what the post-React world should look like:

https://infrequently.org/2024/11/if-not-react-then-what/

This is a cool website:

https://vanillaweather.com/

This is *extremely* well done:

https://crukorg.github.io/engineering-guidebook/docs/best_practices/frontend/choosing_your_stack/

Bravo to @hasanhaja et. al.

Going to put this next to gov.uk's PE guidance and Mu-An's "when to use JavaScript" as default recommendations to teams:

https://muan.co/posts/javascript

https://www.gov.uk/service-manual/technology/using-progressive-enhancement

/cc @tomski @muan

At absolutely no point in the 2020s should you, or anyone you don't hate, start a project with React.

There are a lot of reasons for this -- that it's legacy tech built for a world where IE 6 still had measurable share, that the Reactor community has been wrong about everything all the time for a decade+, that the money you'll save can be measured in truck-loads -- but the *most* important is that it will opt you out of the godforsaken React discourse.

Be free! Never look back. Do engineering.

@mccrodp This will sound glib, but the real tension today is between the assumption of framework-silo'd development and thinking about user needs. They don't *sound* like opposites, but I promise that they are.

The advice I give most teams it to start with user needs:

https://www.gov.uk/guidance/government-design-principles

And then follow progressive-enhancement as far as it will take you:

https://www.gov.uk/service-manual/technology/using-progressive-enhancement

This will put server-generated HTML+CSS back on the menu, which is a lifesaver.

So bsky's site is...what's the word?...bad, performance-wise. [1]

I pointed this out, and folks asked what I'd do differently. I had to preface the response by saying that you don't start any new projects with React in the 2020s because it was designed for the (early) 2010s and has aged like fine milk.

This drew out a reply by someone saying that *they* start with React, but *they* know what they're doing, and all I can think is "does your boss know?"

[1]: https://treo.sh/sitespeed/bsky.app?mapMetric=r&formFactor=phone&metrics=lcp%2Cr

Writing a blog post about AMP. It doesn't quite fit, but the subhead *"Beware of Geeks Bearing Grifts"* is double-dog-daring me not to use it.

You don't need to imagine a conspiracy to suppress the web by slow-rolling important new features when the base-case is that the APIs that *are* implemented are indistinguishable from elaborate practical jokes.

This continues to be *extremely* relevant:

webventures.rejh.nl/blog/2024/history-of-safari-show-stoppers/

Just yesterday in the Web Performance Slack, folks were trading advice about how beat the keep-Safari-from-fucking-up-scrolling challenge (impossible)

@benschwarz Yeah, lots of people focused on bad things it wasn't facilitating rather than the bad things it did. Didn't help that most publishers were delusional about the performance of their pages.

So I've got a bsky acct, and y'all, their web app is everything I warn about. It's React (because they have capitulated to the App Store game via Expo and "need" React Native), but it's also web-as-afterthought-flavoured React. Which is going just about as well as you might expect for folks who don't own the latest devices:

https://www.webpagetest.org/video/compare.php?tests=241115_BiDcDR_7GP-r:1-c:0,241116_BiDc3C_3VN-r:1-c:0

Mastodon's React mistakes pale in comparison and, ofc, @nolan's pinafore.social blows them both out of the water. Failure this bad is a choice.

@nolan This is a choice, specifically, about class and inclusion. For the benefit of the enfranchised and the comfortable, Bluesky is making their service less accessible to folks who are less wealthy. The pushback I get when pointing out how utterly incompetent their web 2.4MB critical path JS bundle (and fonts served without compression) are is invariably a sort of reflexive defense about how they're "trying so hard" and "just a small team" (rinse, repeat).

And it's both true and telling.

@muan @sayrer 11ty builds are so fast (if you don't lard up the pipeline) that the rebuilding thing isn't a problem in practice.