So bsky's site is...what's the word?...bad, performance-wise.
-
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.
-
Mia ‘Meetings? I Abstain’ Luna Tearmoonreplied to Alex Russell last edited by
@slightlyoff this is an amazing series and makes me recall how half of the questions the axum web framework's channel in tokio Discord used to get was ‘how do I host an SPA’ (and how for each of these, I want to answer ‘you don't, please rethink’)
