The React Reckoning: Is the Industry's Favorite Framework Still the Right Choice?
For over a decade, React has been the gravitational center of frontend development. Its introduction of the Virtual DOM and declarative components revolutionized how we build user interfaces, moving the industry away from the "jQuery soup" of the early 2010s. However, a growing chorus of developers, CTOs, and engineers is now asking a provocative question: Does anybody actually like React?
Recent discussions across Hacker News and technical blogs suggest we are entering a "post-React" era—not necessarily one where React disappears, but one where its status as the default choice is being aggressively questioned. The critique is no longer just about syntax; it is about performance, security, and the fundamental architecture of the modern web.
The Case Against the Monoculture
One of the most pervasive criticisms is that React has become a "hammer that makes everything look like a nail." The industry has fallen into a reflex where the conversation around a new project starts with "Let's use React; everyone knows React," rather than "What are the constraints and which tool best fits them?"
This network effect has created a self-perpetuating cycle. Because most developers know React, companies hire React developers, which in turn encourages more developers to learn React. However, this "labor arbitrage" often comes at a technical cost. Critics argue that this monoculture kills frontend innovation and leads to over-engineered solutions for simple problems.
Technical Debt and the "Insanity" of Complexity
Beyond the social dynamics, there is a deep-seated frustration with React's evolving complexity. The shift from class components to Hooks, and now toward React Server Components (RSC), has left many feeling that the framework is playing a game by its own rules.
The Hook Struggle
Many developers find React's hooks—specifically useEffect and useMemo—to be counterintuitive and difficult to master. As one commentator noted, hooks are "tricky to use correctly and even harder to use in a performant way," often leading to spurious re-renders and a "churn" that degrades the user experience.
The Hydration Tax
React's default hydration pattern is frequently cited as a performance bottleneck. The process of rendering HTML on the server and then "hydrating" it with the same JavaScript on the client is seen by some as redundant and wasteful. This "JS-heavy approach" is argued to be incompatible with long-term performance goals, particularly for users on low-end hardware or slow connections.
Security and Governance
Recent security vulnerabilities, including a critical remote code execution (RCE) flaw in React Server Components (CVE-2025-55182), have heightened concerns. Some developers have expressed frustration not just with the bugs, but with the governance and communication from Vercel and the React team, describing some responses as "reckless and disrespectful to the community."
The Alternatives: From Svelte to Vanilla HTML
As the frustration grows, developers are migrating toward a variety of alternatives, each solving a different part of the React problem:
- Svelte and Solid.js: These frameworks are praised for moving the work from the browser to a compile-time step, removing the need for a Virtual DOM and resulting in faster, leaner applications.
- Vue: Some find Vue's model—where components run once and set up a reactive tree—to be more intuitive and less prone to the manual optimization required by React.
- HTMX and Liveview: There is a resurgence of interest in "Hypermedia" systems that push logic back to the server, reducing the amount of JavaScript shipped to the client and simplifying the state management process.
- The "HTML-First" Approach: A growing movement advocates for returning to web fundamentals—baseline HTML with progressive enhancement—to ensure accessibility and performance.
The Counter-Argument: Why React Still Wins
Despite the onslaught of criticism, many developers still defend React. The arguments in its favor are often pragmatic:
"React is the worst JS framework except for all the others we've tried."
For many, the elegance of JSX and the simplicity of the "component as a function" mental model outweigh the frustrations. Proponents argue that the declarative, component-based approach is the only way to manage truly complex UIs at scale, and that manual DOM manipulation is a recipe for unmaintainable "spaghetti code."
Furthermore, the ecosystem—libraries like TanStack Query and the vast array of community-driven components—provides a level of tooling that alternatives have yet to match. For these developers, the "slop" of a corporate codebase is a result of bad engineering culture, not a flaw in the tool itself.
Conclusion: A Shift in Perspective
The debate over React is less about whether the framework is "good" or "bad" and more about whether it is the right tool for the majority of the web. The industry is beginning to realize that the "fat client" era of JS-heavy frontends may have peaked.
Whether the future is a return to server-side rendering, a shift toward fine-grained reactivity, or a hybrid approach, the lesson is clear: the era of the default framework is ending. The most successful engineers of the next decade will likely be those who can look past the hype and choose the tool that fits the specific constraints of their project, rather than the one that is most popular on a resume.