DEV Community

Cover image for React's harsh reality: A Must-Read Insight by Alex Russell
Matti Bar-Zeev
Matti Bar-Zeev

Posted on • Edited on

React's harsh reality: A Must-Read Insight by Alex Russell

I’ve just come across what might be the most insightful article I’ve read in ages. Titled “If Not React, Then What?”, it’s authored by Alex Russell, a Partner Product Manager at Microsoft Edge.

This piece profoundly resonated with me. As I read through it, nodding in agreement with each paragraph, it became clear that I had to share it with you. I started jotting down standout quotes that truly hit home, and before long, I realized I couldn’t confine my reflections to just a handful of tweets—this deserves a wider stage.

The article scrutinizes the entire Frontend ecosystem, with a particular focus on React, presenting a well-supported critique underpinned by extensive data and resources. It casts light on the sobering realities of frontend development, challenging the industry’s collective direction and exposing the ‘herd mentality’ that seems to dominate.

In all seriousness, this is essential reading for any frontend developer or architect.

If Not React, Then What?

It’s a substantial read—about 9.5k words—but before diving in, let me share some of the most compelling excerpts that deeply resonated with me


“In short, nobody should start a new project in the 2020s based on React. Full stop.”

“It's the rewarding side of real engineering, trying out new materials under well-understood constraints to improve user outcomes.”

“Technologies come and go, but what always makes the difference is giving a toss about the user.”

“… And only when an SPA architecture is required should tools designed to support optimistic updates against a local data model — including "frontend frameworks" and "state management" tools — ever become part of a site's architecture.’

“Editors of all sorts are a natural fit for local data models and SPA-based architectures to support modifications to them. However, the endemic complexity of these systems ensures that performance will remain a constant struggle. As a result, teams building applications in this style should consider strong performance guardrails, identify critical user journeys up-front, and ensure that instrumentation is in place to ward off unpleasant performance surprises.”

“This is because the dominant outcome of fling-stuff-together-with-NPM, feels-fine-on-my-$3K-laptop development is to cause teams to get stuck in the mud much sooner than anyone expects.”

“‘...it works for Facebook’
To a statistical certainty, you aren't making Facebook. Your problems likely look nothing like Facebook's early 2010s problems, and even if they did, following their lead is a terrible idea.”

“React knowledge is also not particularly valuable. Any team familiar with React's...baroque...conventions can easily master Preact, Stencil, Svelte, Lit, FAST, Qwik, or any of a dozen faster, smaller, reactive client-side systems that demand less mental bookkeeping.”

“... heroes that will do incredible good for your products at a fraction of the cost of solving the next problem the React community is finally acknowledging that frameworkism itself caused.”

“The idea that folks who have mastered the horrors of useMemo and friends can't take on board DOM lifecycle methods or the event loop or modern CSS is insulting. It's unfairly stigmatising and limits the organisation's potential.”

“‘...React is industry-standard’
This is, at best, a comforting fiction.”

“Across more than 100 consulting engagements, I've never seen two identical React setups save smaller cases where developers have yet to add to the defaults of Create React App (which itself changed dramatically over the years before it finally being removed from the React docs as the best way to get started).”

“... And if you don't mind me asking, how's that "CSS-in-JS" adventure working out? Still writing class components, or did you have a big forced (and partial) migration that's still creating headaches?”

“... consider NPM dependencies like a sort of high-interest debt collateralized by future engineering capacity.”

“Sites built with Next.js perform materially worse than those from HTML-first systems like 11ty, Astro, et al.”


Photo by Lautaro Andreani on Unsplash

Top comments (1)

Collapse
 
xwero profile image
david duymelinck

I read it before I saw your post. The quotes you added are the ones that also caught my eye.

Other quotes that made me think are;

"Even folks with deep expertise in, say, Rails and ERB, can easily knock out Django or Laravel or Wordpress or 11ty sites. There are differences, sure, but every web developer is a polyglot."

You will get the best results in the language you are most familiar with. But I think backend developers are more used to check out other languages. And if you have some time under your belt with another language It will be possible to achieve some result, but most of the times you are going to need help from someone who has deeper knowledge of the language to get the best result.

"Client-side web development is perhaps best conceived of as influence-oriented programming. Once code has left the datacenter, all a web developer can do is send thoughts and prayers."

It is an exaggeration, but it is a reality that you can apply to each product that is used by others. You can't stop people from doing things with the product the creators didn't think about.
That is why the next quote is the main takeaway for me.

"the only thing that makes web experiences good is caring about the user experience"

When people have a good experience using the product, they are less likely to try to find out of the box ways to overcome the things they don't like.
I just saw a video where they advised to scan one finger multiple times in different positions. This allows for a better recognition when you need to use it for identification. A way to solve this is a scan that suggests to move your finger instead of lifting it, if the scanner is smart enough to connect the patterns.