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

*"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.

One of the teams I've been working with to climb the performance management maturity ladder is...Edge!?!

We build a *lot* of the browser out of web "stuff" these days (think bookmarks, history, downloads, settings, new-tab-page, etc.), and moving away from React to a modern Web Components + HTML-first architecture has had a *huge* benefit for users, particularly folks on low-end hardware:

https://blogs.windows.com/msedgedev/2024/05/28/an-even-faster-microsoft-edge/

#webcomponents #webperf #usetheplatform #sorrynotsorry

It's easier to start light and stay fast when you're sticking closer to the platform. That's why thinking in terms of progressive enhancement is such a win for performance. But putting guard rails in place, managing for speed, and building expertise and leadership in the team that value the *lived* experience are the most important ingredients.

A mature team can manage any tech; an immature team will see even the simplest systems get away from them:

https://infrequently.org/2022/05/performance-management-maturity/

This is building on the same open source, FAST-based design system ("Fluent Web Components v3"):

https://github.com/microsoft/fluentui/tree/master/packages/web-components

But the framework isn't what makes the difference; actually *looking* and *caring* about the performance is what has enabled this work to deliver 40-75% wins.

Governments around the world have found exactly this every time they've looked hard at Apple keeping competing browsers at bay, but crikey. The DOJ is not playing around:

Apple's attempt to knife PWAs in the EU will have worldwide implications if allowed to stand. Not knowing if Push Notifications will be available or data will be lost will drive developers back to native, punishing investments in the web worldwide, even if the change is only "real" in the EU.

This is as bad as it sounds. If you want to fight back, join @owa in supplying information to regulators about what it will mean for users and developers:

https://open-web-advocacy.org/apple-attempts-killing-webapps/

I posted the @owa end-of-year update [1] yesterday, but this bit really got me.

These folks are working in the shadows to constantly brief regulators on extremely complex browser competition issues. They're web developers who, instead of making websites, are endlessly preparing presentations and documents for regulators to make a better web possible.

If you want to stand up for the web in '24, they can use your help:

https://open-web-advocacy.org/get-involved/

[1]: https://open-web-advocacy.org/blog/owa-2023-review/

*"no one ever got fired for choosing React"* is, AFAICT, not true today, and never has been.

I've witnessed entire teams get flushed and VPs get unceremoniously booted on the other side of grand React redesigns tanking revenue and conversions.

None of those folks talk publicly about how it went down because doing so would simultaneously devalue the thing they've invested in and hurt their own employability within that world. And so we bumble on, omerta in tact.

@adamhill A cultural failure to value the marginal user and engineer to their constraints. This leads teams to assume that their own computing situation (fast devices/networks/etc.) are a fine substitute for the business' users.

This has been growing ever-more-wrong as mobile devices proliferate, but PMs have not gotten wise to it yet. Some new metrics like INP are shining a light, and may cause a shift, but at this point we've grown a whole generation of "I've got mine, Jack"-ists

A whole lotta people are about to realise that alternative app stores full of native apps are terrible, actually, and what they really want are PWAs.

Updating the Performance Inequality Gap series [1] (post soon), but here's a teaser: new CPU charts, by price band. Single-core perf matters for web apps, and I won't sugarcoat; it's grim.

The fastest Androids are half as fast as contemporary iPhones (now 4+ years behind) and volume devices (~$300USD) are 1/5th as fast as iPhones.

Building for iPhones erects walls around wealth and precludes effective access to participation in society for those without means.

[1]: https://infrequently.org/series/performance-inequality/

The good news is in multi-core, where the gap is still growing, but not as fast. This is in line with new process nodes finally reaching the lower-end of the price curve, but Qualcomm, MediaTek, etc. have a LOT to answer for. The failure to add meaningful caches and compete on performance continues to harm not just the high-end, but trickles down in a terrible way.

Anyway, if you think you can afford to build with React or Angular in 2023/2024 because phones keep getting faster, congrats, I guess, for being consistent?

Consistently wrong – hasn't been even moderately plausible for a decade – but consistent.

None of this is new, and none of the bad effects have abated at scale enough to relax. New projects are still being started on react and angular. The JS emitters have no shame because they largely don't think they did anything wrong.

Something something "interactivity" (for rich users) something something.