React remains the most widely used frontend framework, but several pain points in large projects are recurring, real topics of community discussion. This article organizes those arguments by problem domain. It does not claim a definitive “replacement” — it states facts and points of view.

1. Performance: diminishing returns from the virtual DOM

The core value of the virtual DOM is reducing direct DOM operations. When pages are data-heavy and updates are frequent, diffing and reconciliation become overhead themselves. The React team keeps improving this via Fiber and concurrent features, but the optimization tools (memo, useMemo, useCallback) require active, error-prone maintenance.

The common industry view: the virtual DOM pays off clearly for small and medium pages; for high-frequency interaction with large datasets, the benefit shrinks. React Compiler (automatic memoization) is the official response to this problem, but it was not the default at the time of writing.

2. Complexity: the cognitive load of Hooks rules and state management

React’s API surface expanded quickly after 2016: Hooks rules, concurrent mode, Suspense, Server Components. Each addition has a rationale, but combined they make the learning curve steeper. The state management ecosystem (Redux, Zustand, Jotai, XState) has long been fragmented, and teams must pick and stay consistent across paradigms.

This is not a flaw per se — it is a natural result of framework evolution. But for small teams, “spending business-code time on framework concepts” is a real feeling, and it is precisely the “fewer concepts” selling point of frameworks like Svelte.

3. Talent: experienced React developers are in short supply

The React developer pool is large, but developers who can actually steer large React projects remain scarce. Not because React is hard to learn, but because the tacit knowledge of large projects (performance work, architecture, ecosystem choices) sits with a minority. This is a market phenomenon independent of the framework’s quality — but it directly affects hiring cost and technical debt risk.

4. Ecosystem churn: refactoring costs are underestimated

State, routing, and data-fetching libraries churn fast, and upgrades often bring breaking changes. For long-lived projects this means a permanent refactoring budget. The Redux → Redux Toolkit and CRA → Vite migrations are the two most typical examples of recent years.

5. Dependency size: node_modules and supply-chain risk

A medium React project can have thousands of packages in its dependency tree. Size affects build and load performance; supply-chain risk (compromised or abandoned dependencies) is a long-term concern for security teams. This is not React’s fault — it is a general npm ecosystem issue — but it is most visible in React projects.

Alternative paths the community offers

These options each fit specific scenarios; none is a universal “React killer”:

  • Svelte / Solid: compile-time optimization that moves framework overhead into the build step, with a lighter runtime. Good fit when bundle size and first paint matter.
  • Astro: island architecture, static by default, interactive parts loaded on demand. Good fit for content-heavy sites.
  • Vanilla JS + light tooling: for simple pages, skipping framework abstraction can be more controllable.
  • WebAssembly: compute-heavy scenarios (data analysis, image processing) move down to WASM, orthogonal to the frontend framework.

Conclusion

React will not disappear, but its position is shifting from “default choice” to “one of the choices.” For developers, understanding the boundary conditions of these pain points (when they hold, when they don’t) matters more than picking a side. Stack decisions come down to two questions: how high is your page’s interaction density, and how much maintenance cost can your team absorb?

Note: this is an opinion piece without specific company case data; any performance figures should be verified against official benchmarks and your own project measurements.