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.
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 (0)