Notices by Alex Russell (slightlyoff@toot.cafe)

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.

@konnorrogers @muan @sayrer +1. Lots of folks instinctively add "optimization" passes to re-create small savings from JS-industrial-complex stacks that turn out not to matter if you just stick to modern HTML/CSS.

"Every little bit of uncaring makes the world a little bit worse, and once you're at a certain level of personal security then you have to own that."

https://ludic.mataroa.blog/blog/why-i-will-always-be-angry-about-software-engineering/

/by @ludicity
/via @fugueish

"The framework isn't the problem!" is something I've been hearing the apologists for lemon vendors spout for going on a decade now, and I think we need to decapitate this zombie idea once and for all.

First, *I know* that 45KB of JS isn't going to break the bank. Duh. That's not the point. The point is that the apologists *don't even have budgets*. Which means that *every* increment above zero is *a priori* too much!

Folks that can't say "when" aren't sophisticated enough to be using JS.

This is because the toolchains and architectural assumptions of NPM-based frontend culture are *fucked*. Totally and utterly divorced from what delivers acceptable results for most people, most of the time -- both as users, and as businesses.

This deep truth sits underneath everything else: *the way* these frameworks and ecosystems present to the developer assumes they have no self-control and do not know better. All while justifying their wares on the basis that everyone, instead, has mastery.

Which leads to the next point: the justification for client-side JS is invariably "interactivity".

But I can count on one hand the number of teams that have done bake-offs to *measure* if one library or approach will improve interactivity for representative users. Even teams that have tons of data about their userbase *do not do this* today! It's a lost art.

And unless an org is practicing the lost art of bake-offs, *it is not sophisticated enough to bet on JS*.

A brief work interlude: we're hiring a lead Web Platform PM! A chance to work closely with Edge's platform (and Chromium) team in a strategic role, working closely with me and other PM leads:

https://jobs.careers.microsoft.com/global/en/job/1779414/Group-Product-Manager%2c-Microsoft-Edge-Web-Platform

*All* of this is JS-optional, progressively enhanced HTML. All of it.

https://hachyderm.io/@joelanman/113426368169223915

For the avoidance of doubt, that was 300K *COMPRESSED*, so something like 1.5MB of JS source.

The worst thing the Reactors ever did was to convince people that their own dreams of infinite network and CPU abundance into the future were real, when in fact they were just playing themselves.

It's 2024, the web platform now includes a full component system, CSS we only dreamed of 10 years ago, deferred module loading is now a platform feature, and a fuller JS standard library than it ever...even in Safari!

And yet.

Today I was told unironically that 300K of JS was a hard target to hit for first load of a simple-ish experience.

I am verklempt.

Your blog does not need frameworks built for SPAs.

Your e-commerce "experience" should be progressively enhanced (no, that does not mean "SSR+huge bundles")

Your news website is not "an app".

Part 3 of my series on how JavaScript fucked over US public benefits services is up, and includes a handy rubric for "should we React?"

https://infrequently.org/2024/08/caprock/

It clicked for me this morning: the thing that sucks about frontend's lost decade's and the obsession with remaking every blog and marketing microsite as "an SPA" (dragging MBs of JS in tow) is the same thing that sucked about Java Applets.

You can promise "richness" and "app-like UI" all day, but if the experience sucks in point of fact, then you're just gonna nerf your own ecosystem's potential.

The shame of the JS-industrial-complex is that the ecosystem they're doing it to is the web.

And dear *effing* lord, do *NOT* let React anywhere near your codebase in 2024. At least make new mistakes.

PMs/EMs: I'm *begging* you to stop needing my services. I do *not* want to hear from your team! They're probably lovely, but your website drowning in JavaScript isn't, like, a novel challenge. I've seen *dozens* of identical patients, and it's alternatively boring and heartbreaking.

So, please, keep yourself from ending up in the long line of folks I have to check in on regularly who are *still* digging out from JS disasters. Don't add yours to the list of low-velocity orgs, mired in script.