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.
@steadicat @bendelarre: sorry, but no. At runtime, React adds complexity for every single feature that depends on it. That is a multiplier on the scale factor for difficulty of managing it later on.
And that's directly related to the way that React forces features to be delivered the most expensive way (at runtime, via JS). That's a large constant drag on team velocity and UX over time.
Alex Russell
Stefano J. Attardi
Ben Delarre