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

@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.

*"But our team knows React..."*

THAT IS NOT A THING. They don't know "React", they're on a continual treadmill[1] of React sub-variants, bundler configuration micro-languages, and one-off plugin amalgamations.

THERE IS NO INDUSTRY STANDARD REACT STACK. IT DOES NOT EXIST OUTSIDE OF TOYS.

And if your website is a toy, why would you let that nonsense anywhere *near* the door when simpler, cheaper options have always existed?

[1]: https://polotek.net/posts/the-frontend-treadmill/

A handy list of folks to never do business with; not because they're fascist, but because they're too fucking stupid to understand what happens when fascists win power. Don't fuck with craven:

https://sfstandard.com/2024/07/17/musk-andreessen-horowitz-tech-silicon-valley-trump-biden/

I'm glad to see Mozilla move from throwing stones to offering solutions:

https://www.reddit.com/r/firefox/comments/1e43w7v/a_word_about_private_attribution_in_firefox/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

That said, we're in an even worse place w/ the privacy discourse than Bobby's note implies. The threat is data at rest, and attenuating collection (as Apple has implied is the way forward) doesn't actually solve the problem, it only narrows it somewhat.

The strong solutions involve toothsome privacy laws. And until the "privacy is a human right" companies push on *that*, it's all performative.

For my sins, I was taken down the rabbit hole of a document called "The Carbon Impact of Web Standards" (no, I'm not linking to it).

Friends, I feel nauseous. I'm getting dumber just leaving this tab open. Does it start with a situated analysis of the potential contribution of web content to overall GHG emissions? Lol, no.

Nor does it start from any estimate of real-world site construction (e.g., via the HTTP Archive).

It's so, so much worse.

I shit you not, the methodology is to load small-ish web pages with *no JS*, totally ignore power use from screens and radios (you know, the big ticket items?), guestimate that the average device uses power like a gaming rig, then do shoddy multiplication.

To what end? To try to extrapolate how much energy `<div>` or `<video>` use, totally ignoring the actually dominant factors.

This is WILD.

This is an *absolute banger* of a long read about the omnishambles of Lambda School:

https://www.sandofsky.com/lambda-school/

It caused me to look up their current "web developer" syllabus; I think we can draw a straight line from the *horrible* education that otherwise great people are getting at overpriced diploma mills to the shockingly poor results in contemporary web products:

https://www.bloomtech.com/courses/full-stack-web-development#curriculum

It's a sallow thing that the 20th century gave us Bertrand Russell, Arendt, Orwell, and Popper only to have their mountain of clarity torn down by the very forces they documented and warned against.