So bsky's site is...what's the word?...bad, performance-wise.
-
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
-
The number of times over our Lost Decade I've heard people (men) confidently assert to me that they knew what they were doing with React as we casually perused the incontrovertible evidence that they did not, in fact, know what they were doing is unsettling.
-
@slightlyoff i've been reading your posts but i think i missed the point of react being made for the early 2010s. does that mean you think it was a good fit for the conditions of that time, but isn't anymore? if so, what exactly changed that makes it a worse fit now? do you elaborate on that somewhere?
-
Alex Russellreplied to * last edited by [email protected]
@[email protected] React was designed for an era where IE 6 still roamed the earth ('11-'12, wasn't OSS'd until '13). The core design choices of a synthetic event system, vdom, and hard-coded element list were premised on CPUs/networks getting faster while trailing edge browsers remained stuck in place.
Then mobile happened and *none* of those priors held. OldIE died out & mobile meant that CPU and network progress effectively halted. I keep writing it up:
Reckoning: Part 1 — The Landscape - Infrequently Noted
It would be tragic if public sector services adopted the JavaScript-heavy stacks that frontend influencers have popularised. Right?
Infrequently Noted (infrequently.org)
-
@slightlyoff I wrote that comment to you on Bluesky and you didn't reply to me there but went on Mastodon to shit on me. What's wrong with you?
-
Alex Russellreplied to Adam Ziolkowski last edited by [email protected]
@adamzett I did not name you or point to your post. Was using it as a generic example of the sort of thing I get a lot of...but welp.
-
@adamzett So since we're here, why do you pick React when you're presumably familiar with all the ways it leads teams down the primrose path?
-
@slightlyoff What do you suggest using instead?
-
@slightlyoff I also think that businesses need exposure to bad outcomes... I was once part of a team rewriting a desktop application written in Java for an arline software supplier. We managed it in a year and everyone thought it was a success. It run well on desktop and mobile browsers. Their first trial happened to be in Ethiopia for their national carrier. Imagine how an app developed for speedy internet connections run on their networks.
-
@adamzett I've seen much of that sort of thing. But the frontend ecosystem isn't learning. The costs are externalised, and/or severely downplayed by those doing the externalising. For markets to work, pricing signals have to be visible; it's why I wrote this last year:
The Market for Lemons - Infrequently Noted
New web services are being built to a self-defeatingly low UX and performance standard, and existing experiences are now pervasively re-developed on unspeakably slow, JS-taxed stacks. At a business level, this is a disaster, raising the question: why are new teams buying into stacks that have failed so often before?
Infrequently Noted (infrequently.org)
-
@vegantacos This will sound glib, but it isn't meant to be: start with user needs. This was written for government, but applies to most sites:
Government Design Principles
The UK government's design principles and examples of how they've been used.
GOV.UK (www.gov.uk)
Also:
Building a robust frontend using progressive enhancement - Service Manual - GOV.UK GOV.UK
How to build web pages so they work in HTML first: starting with HTML, extra styles and features, using JavaScript.
(www.gov.uk)
There are classes of apps that don't fit that guidance, but teams need to show their work as to why they're an exception.
-
@adamzett On the thing about components and libraries, React is the only ecosystem trapped in a monolithic component dogma. Everyone else can mix-and-match with Web Components these days. As for "what folks know", presumably frontend engineers are meant to understand HTML, CSS, JS, and DOM. If they do, they can also do Web Components. React adds very little that lighter weight alternatives don't provide.
I could write a small book about what hiring managers *think* they're getting vs. reality
-
@adamzett But the TL;DR of that is that many people adopt various flavours of in-vogue React stacks only to find themselves alone on a deserted island of uniqueness just as soon as the fads move on. And boy, howdy, do they move on. Lots of teams I work with are going to be spending years digging out of "CSS-in-JS" nonsense that was predictably molasses-like in practice.
-
@adamzett "what the company knows" is also vastly oversold. Most senior folks weren't React developers that long ago, and they could easily move to Preact (or Lit, or Svelte, or Qwik, or Stencil, or anything else) extremely quickly. The rest of these stacks are either bespoke or nearso (various router bits that are constantly changing, "state management" stuff that isn't actually that, etc.).
I've consulted with more than 100 teams over the past 8 years and none have had identical React stacks.
-
@slightlyoff I'm having a hard time with your footnote #7 on the page - while I think the "bullshit hierarchy" may be true, what you've linked it to is Google's reluctance to get on the JS Train and I think surely, at the time, there was legitimate reasons to be wary? JS really WAS still a toy language 15 years ago - you say yourself that Google needed to invent the whole V8 VM to get any performance out of it (huge engineering investment), the tooling was godawful. Coupled with its monopoly on in-browser scripting, "either use this bad language everyone hates or go home" doesn't seem like a clearly winning move for setting priorities...
I guess I'm just kind of struggling to understand your argument here
-
@greg The fights we had to get frontenders promoted were some of the worst of my career. The multi-year effort to reform the recruiting/hiring/promotion pipeline was Not Fun (TM). The survivorship biases built into perf made it *extremely* hard to get frontend folks recognition.
-
@greg All of that was post Gmail/Maps/Reader/Docs. The people who built those (extremely great) frontends were not recognised. The skills they brought were not valued. Their promotions were endlessly litigated. And woe to the folks following behind without their stature!
-
@greg And no, JS was not a toy pre-V8, it was just orders of magnitude harder to do well. This assumption is perpetuating the bullshit. Don't be that person.
