Why I Ditched React and Never Looked Back
Why I Ditched React and Never Looked Back
I’ve been using React since around 2016. Back then, React felt like the future — a way to build UIs that was both declarative and component-based, finally moving away from jQuery spaghetti and DOM micromanagement.
For years, it was my go-to framework. I built SaaS products, internal tools, mobile apps via React Native, and dozens of prototypes. I knew the ins and outs of React: from useState to useReducer, from lifting state to composing providers.
But after nearly a decade of using React, I walked away. Not with regret or anger — but with clarity.
Here’s why.
1. Boilerplate Burnout
Modern React development involves a staggering amount of scaffolding. Want to manage global state? Set up Context or Redux. Need a form? Bring in Formik or React Hook Form. Want animations? Here comes Framer Motion or React Spring. Need to fetch data? Add useEffect, useState, or even a library like React Query or SWR.
Don’t get me wrong — these tools are powerful. But they also represent a growing cognitive load.
Simple features often require an intimidating stack of boilerplate. A dropdown might need three files, a context, and a memoized callback just to function properly. You don’t notice it when you’re deep in the ecosystem — but step outside it, and the contrast is jarring.
Once I started exploring alternatives, I realized: a lot of this complexity isn’t necessary.
2. Tooling Overload
React doesn’t ship with batteries included — and that’s both a strength and a weakness. You choose your own router, state manager, form library, testing tools, and even your own build system (Vite? Webpack? Parcel?).
This modularity gives freedom, but also fatigue.
Compare this to something like SvelteKit or Astro, where routing, data loading, transitions, and even head management work out of the box. Less time configuring means more time building.
I was tired of wiring things up for hours before I even wrote my first component. React development started to feel more like assembling a car from a thousand separate packages than designing a great user experience.
3. The Performance Trap
React is fast — but it’s not lightweight. Virtual DOM diffs, reconciliation, unnecessary re-renders, and the constant battle against performance regressions made me question whether I was optimizing the framework instead of the app.
I’ve spent too many hours debugging slow component trees with React DevTools. Memoization, splitting components, preventing prop drilling — these aren’t “advanced” techniques anymore. They’re basic survival.
Then I tried SolidJS. It skips the virtual DOM entirely, and reactivity is built in at the language level. It’s not just fast — it’s instant. Suddenly, I didn’t need to think about performance — it just worked.
The moment you stop thinking about “shouldComponentUpdate”, you realize how much of your brain React was borrowing.
4. Developer Experience Shouldn’t Hurt
React can be elegant, especially in the hands of experienced developers. But that elegance comes at a price.
I got tired of constantly checking dependency arrays in useEffect. I got tired of jumping between four files to manage one form. I got tired of debating “should we use Redux Toolkit or Zustand?”
Then I tried Svelte. I wrote components that looked like HTML, had scoped styles, and just… worked. I didn’t need an effect to track state. I didn’t need to wrap my brain around stale closures. I could use await directly in the template if I wanted to.
The DX was refreshing — because it didn’t fight me.
I wasn’t writing less code just for the sake of brevity. I was writing less because the framework got out of the way.
5. Most Projects Don’t Need React
This one hit hardest: the realization that most of the projects I built in React didn’t need it.
Internal tools, marketing sites, simple dashboards — they didn’t benefit from React’s component architecture or its state management. In many cases, plain HTML + Tailwind + a sprinkle of Alpine.js or HTMX would’ve done the job better, faster, and with far fewer dependencies.
React is built for ambitious, interactive, state-heavy interfaces. But not everything needs to be an SPA. By using React for everything, I was often overengineering my solutions.
Sometimes, less is more. And simpler tools make it easier to ship, iterate, and maintain.
So What Did I Switch To?
My current stack varies by project — and that’s the point. I now use:
- SvelteKit for reactive, interactive apps
- Astro for content-heavy sites and blogs (like this one!)
- HTMX + Go or Express for ultra-lightweight server-driven tools
- SolidJS when I need React-level interactivity but want better performance
The key isn’t choosing a “React killer” — it’s realizing that React doesn’t need to be the default anymore.
Final Thoughts
I don’t hate React. I’m grateful for what it taught me. It shaped modern frontend development and introduced concepts that changed the industry.
But for me, the tradeoffs no longer make sense. There are lighter, faster, and more enjoyable alternatives that fit my projects — and my brain — better.
Walking away from React wasn’t an act of rebellion. It was an act of optimization.
Have you outgrown React too? What did you move to — and was it worth it? Let’s share war stories in the comments.