React-by-default has hidden costs. Here's a case for making deliberate choices to select the right framework for the job.
React Won by Default – And It’s Killing Frontend Innovation
React is no longer winning by technical merit. Today it is winning by default. That default is now slowing innovation across the frontend ecosystem.
When teams need a new frontend, the conversation rarely starts with “What are the constraints and which tool best fits them?” It often starts with “Let’s use React; everyone knows React.” That reflex creates a self-perpetuating cycle where network effects, rather than technical fit, decide architecture.
Meanwhile, frameworks with real innovations struggle for adoption. Svelte compiles away framework overhead. Solid delivers fine-grained reactivity without virtual-DOM tax. Qwik achieves instant startup via resumability. These approaches can outperform React’s model in common scenarios, but they rarely get a fair evaluation because React is chosen by default.
React is excellent at many things. The problem isn’t React itself, it’s the React-by-default mindset.
The Innovation Ceiling
React’s technical foundations explain some of today’s friction. The virtual DOM was a clever solution for 2013’s problems, but as Rich Harris outlined in “Virtual DOM is pure overhead”, it introduces work modern compilers can often avoid.
Hooks addressed class component pain but introduced new kinds of complexity: dependency arrays, stale closures, and misused effects. Even React’s own docs emphasize restraint: “You Might Not Need an Effect”. Server Components improve time-to-first-byte, but add architectural complexity and new failure modes.
The React Compiler is a smart solution that automates patterns like useMemo / useCallback . Its existence is also a signal: we’re optimizing around constraints baked into the model.
... continue reading