By ByteBot
Developers are publicly declaring they’re done with React in 2025. The framework that powered Facebook, Airbnb, and Netflix is being called “bloated,” “overengineered,” and “designed for 2013, not 2025.” React apps ship 44.5 KB of framework code compared to Svelte’s 1.8 KB—a 25x difference. Migration stories flood Medium and DEV Community with titles like “React Is Dead” and “Why I Stopped Working with React.js in 2025.” But here’s the uncomfortable truth nobody wants to say out loud: The problem isn’t React. It’s you.
React Bloat is a Misapplication Problem
React is a tool designed for complex, interactive applications. Facebook-scale apps. Airbnb-scale booking flows. Netflix-scale video interfaces. When you force it onto a simple marketing site, a three-page form, or a static blog, you create bloat that React never asked for.
Here’s what really happens: Developers stack Next.js for SSR, Redux for state management, Tailwind for CSS, TanStack Query for data fetching, and React Router for navigation. By the time you write a single line of business logic, you’re shipping over 1MB of framework code. One developer reported a 600KB source folder ballooning to a 1.7MB bundle. Another admitted adding Redux state management for a single dropdown menu.
Aleksandr Ross, writing about over-engineering in React projects, puts it bluntly: “Adding a state management library for a single dropdown menu is overkill. Simpler solutions, like local component state, suffice.” He warns he’s “witnessed entire projects get abandoned because organizations couldn’t find developers willing to support overcomplicated codebases.” Simple tasks that should take one day balloon to three because developers must decipher layers of unnecessary abstraction.
You don’t need React, Next.js, Redux, Tailwind, Zustand, and TanStack Query for a marketing site. You don’t need client-side routing for a contact form. You don’t need global state management for a blog with no interactivity. But developers choose React as the default regardless of project complexity, then blame React for the bloat they created.
Svelte and SolidJS Win Because They’re Harder to Misuse
React ships 44.5 KB of framework code gzipped. Svelte ships 1.8 KB—a 25x difference. Typical Svelte apps bundle at 2.6 KB gzipped compared to React’s 40-100 KB baseline. SolidJS offers React’s API without the virtual DOM overhead, now powering apps at Netflix, Cloudflare, and Microsoft.
These frameworks aren’t winning because they’re objectively better. They’re winning because their architecture makes it harder to shoot yourself in the foot. Svelte and SolidJS compile to vanilla JavaScript at build time. There’s no runtime overhead. No virtual DOM diffing. No framework baggage. Direct DOM manipulation means there’s no room for a massive dependency stack.
React’s flexibility is its curse. Being “unopinionated” means no guardrails against complexity. You can add dependencies until your bundle hits 1.7MB, and React won’t stop you. Svelte and SolidJS force simplicity through compile-time constraints. When your framework compiles away, over-engineering becomes obvious and painful.
The numbers back this up. Svelte downloads grew 300%+ since 2022. 43.6% of developers say they want to learn SvelteKit. SolidJS hit 60,000 users with adoption at major tech companies. Developers aren’t abandoning React because it’s bad—they’re choosing frameworks that match their problem’s actual complexity.
The Culture of Default Choices is Killing React
React has become the default choice regardless of project needs. This is resume-driven development masquerading as engineering judgment. Developers choose React because “it looks good on the CV,” not because the project requires Facebook-scale state management. Junior developers copy enterprise patterns without understanding tradeoffs. Teams cargo cult “Facebook uses it, so we should too” while ignoring that their three-person startup isn’t Facebook.
Redux maintainer Mark Erikson notes that “React is not failing, but its once-default simplicity is now weighed down by new layers of complexity.” The biggest factor? “The additional complexity that SSR and frameworks bring.” Developers feel “the React team lives in a different world from their concerns.” Teams spend more time dealing with React and Next.js specific issues than building features.
The React ecosystem’s “no single default” creates decision paralysis. Every project requires architecture decisions: Next.js or Remix? Redux or Zustand? TanStack Query or SWR? Developers ask themselves, “Will this choice be outdated in six months?” For a simple marketing site, this is absurd overkill.
React’s “unopinionated” philosophy sounds like freedom until you realize it means every project reinvents the wheel. For complex applications, this flexibility is a strength. For simple sites, it’s self-inflicted pain.
When React Actually Makes Sense
React isn’t bad—it’s specialized. Use React for complex, interactive UIs with heavy state management. Admin dashboards. SaaS platforms. Real-time collaboration tools like Google Docs. Large-scale applications with many developers where component reusability across products matters. React’s mature ecosystem, proven enterprise track record, and large talent pool make it ideal for these scenarios.
Don’t use React for static blogs that can be statically generated. Marketing sites with mostly static content. Simple forms spanning three to five pages. Landing pages. Documentation sites. These don’t need React’s complexity. They need HTML, CSS, and minimal JavaScript.
React is a Ferrari. You don’t drive a Ferrari to the grocery store. When you need speed, handling, and performance at scale, React delivers. But most projects are grocery store trips, not Formula 1 races. Choosing React for every project is like insisting on a Ferrari for your daily commute—expensive, impractical, and missing the point.
The Backlash is Healthy
The migration away from React for simple projects isn’t React’s failure—it’s progress. The backlash is forcing developers to question default choices. It’s encouraging framework diversity. It’s promoting “right tool for the job” thinking instead of cargo culting and resume-driven development.
Developers writing posts titled “Why I Decided to Stop Working with React.js in 2025” aren’t wrong to leave. They’re admitting they chose the wrong tool in the first place. One developer captured it perfectly: the framework “that once felt indispensable now feels like a weight.” Another said developers want frameworks “that feel designed for 2025, not 2013.”
React isn’t dying. It’s finding its proper place. Svelte and SolidJS are projected to power 30% of new single-page applications by 2025, and that’s healthy. Framework diversity means developers can choose complexity that matches their problem instead of defaulting to the heaviest tool in the shed.
The real lesson isn’t “React is bad” or “Svelte is better.” It’s “choose complexity that matches your problem.” React remains the right choice for complex applications. But if your project doesn’t need Facebook-scale state management, stop pretending it does. The bloat you’re complaining about? You built it, not React.
React isn’t the problem. Your refusal to admit you chose the wrong tool is the problem. The backlash is developers finally being honest about that. It’s about time.
