Cannot say it often enough: the culture and tools that surround React are not aligned with the discipline needed to deliver good experiences.
From the core model which does not scale, to the community defaults (Redux/Apollo/CSS-in-JS) that tax each feature heavily, it's best to steer clear when and where you can.
Repeatedly I hear teams say that they chose React because they were familiar with it and their schedules mean they just need to ship something asap. Another common reason is that it is easy to hire people who knew it, or that it "has a great ecosystem".
The latter I think is part of the problem, the defaults of the ecosystem are poorly understood. The former two reasons are somewhat similar and not something that is easy for an org to change themselves.
@bendelarre @slightlyoff “Just because it’s popular it doesn’t mean it’s good”. Fair enough. Although as you mention a large ecosystem, community, and hiring pool is a good thing.
But that aside, what makes it “not good”? What alternatives exist that are significantly better?
@steadicat @bendelarre: the community maintains bad norms that undermine products, so maybe that's not the asset you think it is?
As for hiring, this is silly. There's a fire sale on talent right now, and unless you're trying to pay the absolute minimum for the worst work, hire for capacity to grow. Even React stacks are not actually "plug and play"; tons of diversity.
As for alternatives, so, so many! Lit, FAST, Svelte, Stencil, Vue, 11ty, Astro, Enhance, Qwik, Solid, etc. etc. etc.
What are these “bad norms” that undermine products?
And I assume these bad norms are not purely the result of nefarious intentions. What tradeoffs are people making that end up undermining products?
@steadicat @bendelarre: the bad norms stem from narrative inversion; the idea that DX is what matters _most_, rather than the idea that the lived experience of the user is paramount.
I've called this "trickle-down DX", and it's just as thoroughly falsified at this point as the Laffer Curve.
The outcome of this broken narrative is the mis-application of inappropriate abstractions in situations where they can't possibly pay for themselves (CSS-in-JS, Redux, hydration, etc.)
@steadicat @bendelarre: at a community level, this leads to a closing of ranks to protect the (wrong) narrative. Folks *insist* that these abstractions lead to good experiences when for most users that can't possibly be true.
And so those in the privilege bubble reject evidence that this stack isn't working for folks outside it, or even that they'll need much stronger guardrails to actually do a good job.
@steadicat @bendelarre: now, that isn't to say that a fast inner-loop and better productivity isn't a good thing. It's a *great* thing, and I'll fight hard for it for my team(s).
But it's also 100% wrong to think that a fast iteration cycle by it self will lead to a good experience for users on the margins. What leads to better UX is *centering those users in the first place*.
@steadicat @bendelarre: the DX bait-and-switch substitutes what's good for developers for end-user results, and is identical to the sorts of hot-air that sycophants to the wealthy deploy to gain entry to the clubhouse.
In doing so, this narrative substitutes developer vibes for evidence, which takes us away from the scientific method. That's bad!
I agree with most of the points, but I'm not sure I agree with the conclusion.
For example: “100% wrong to think that a fast iteration cycle by it self will lead to a good experience”.
That's fair, but it's also fair to flip it around and say that it’s guaranteed that a slow iteration cycle will NOT lead to a good experience.
Maybe the React ecosystem does not create the optimal UX by default, but it makes the *least optimal* UX (and DX) far less likely.
@steadicat @bendelarre: none of that follows. If we flip it around, all we can say is that focusing on good DX will lead to good DX, and that any improvement in UX will be incidental...which is exactly the situation we're now in. A random walk in which UIs improve and regress in totally unintended ways.
React adds complexity, which is the enemy of reliable performance. Focusing on simpler output for the same features is what helps us manage systems more effectively, ergo React is a liability
@slightlyoff @bendelarre
“good DX will lead to good DX, and that any improvement in UX will be incidental...”
Good DX buys you time to build better UX. No?
“React adds complexity”
It’s true that React adds complexity *up front*, but it pays off in terms of less complexity as the product grows. That’s worth something. Out-of-control complexity as products grow is probably the no. 1 cause of bad UX.
@bitbear @slightlyoff @bendelarre
Are you saying that no amount of developer productivity gain is justified if it could in any way detract from the optimal user experience? Then why are we all still not writing assembly?
And what examples exist of complex, highly-interactive web apps that are purely HTTP+HTML and do not use a complex framework to make the inherent complexity manageable?
@steadicat @bitbear @bendelarre: without a comment on the reductio ad absurdum of invoking assembly, we can focus on the near-peer technologies and note their tradeoffs.
E.g., if you needed reactive UI updates you can pay MUCH less for them on the client from Lit, FAST, Stencil, Svelte, Qwik, Solid, Preact, and many others.
Putting these tradeoffs in the frame of "are we doing well by the user" is key to unlocking a better discussion of the value of each.
@slightlyoff @steadicat @bitbear I feel what often gets confused in this line of discussion is what is React and what is the 'ecosystem'
Reactive UI updates is React, and as Alex says this is easily replaced by smaller, faster, more atomic alternatives. The ecosystem is just a massive collection of random 3rd party libraries smushed together ontop of the framework interfaces React provided over the years.
This isn't intentional architecture, it's a house of cards made from random decks.
@slightlyoff @steadicat @bitbear
Leaning on the React ecosystem to provide you better DX in the hopes it'll provide you long lived reductions in complexity is shortsighted at best and dangerous at worst. Each time you trade DX over UX, framework convenience over platform alignment, you're further compounding complexity and increasing lock-in.
Soon you find the house of cards crumbling, the layers no longer stacking, and you'll have little recourse than to level the whole thing & start over.
@steadicat @slightlyoff @bendelarre No, that's not what I'm saying. An as good opportunity as any to quote the brilliant Dijkstra:
https://icosahedron.website/@bitbear/109393177136699671
The reason we aren't writing in assembly is because C and most languages inspired by it creates "a new semantic level in which one can be absolutely precise" – at least about most things assembly was being used for.
I don't think the same can be said about the React ecosystem (not just the reactive event model). The SPA model itself is in direct opposition to the REST architecture of HTTP. So right out the gate, you have a leaky, imprecise, counter-productive abstraction. And with each part of the ecosystem you add, the abstraction is only going to become less precise and more heavyweight.
As an example of an alternative to React, HTMX is an approach that doesn't try to negate or abstract the fact that it is delivered over a RESTful architecture. It is therefore a much more precise and light-weight abstraction.
Attached: 1 image “The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” — Edsger Dijkstra http://wiki.c2.com/?EwDijkstraQuotes
Alex Russell
Stefano J. Attardi
Ben Delarre
Asbjørn Ulsberg
Asbjørn Ulsberg