Why I Stopped Using React (And You Should Too) 🔥

The framework that promised to simplify everything just made my codebase a nightmare

---

TL;DR: After 4 years of React development and building 20+ production apps, I'm done. Here's why I switched to Svelte and never looked back.

The Breaking Point

Last month, I spent 6 hours debugging a "simple" form component. The issue? useState wasn't updating immediately. Classic React gotcha that still trips up seniors developers.

That's when it hit me: I was spending more time fighting React than actually building features.

The Numbers Don't Lie

Let me show you what switching from React to Svelte did for my latest project:

Bundle Size:
React + Redux: 847kb
Svelte: 23kb

Build Time:
React: 45 seconds
Svelte: 3 seconds

Lines of Code:
React: 2,847 lines
Svelte: 892 lines (same functionality)

That's 97% smaller bundles and 15x faster builds.

The Developer Experience Revolution

Before (React):

const [count, setCount] = useState(0);
const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);

useEffect(() => {
  setLoading(true);
  fetchData()
    .then(data => {
      setCount(data.count);
      setLoading(false);
    })
    .catch(err => {
      setError(err.message);
      setLoading(false);
    });
}, []);

After (Svelte):

<script>
  let count = 0;
  let promise = fetchData();
</script>

{#await promise}
  Loading...
{:then data}
  {count = data.count}
{:catch error}
  {error.message}
{/await}

The Svelte version is not just shorter — it's actually readable.

What React Got Wrong

1. The Virtual DOM Lie

We were told Virtual DOM makes React fast. It doesn't. It adds overhead. Svelte compiles to vanilla JS that directly manipulates the DOM. Result? 3x faster runtime performance.

2. The Ecosystem Trap

React's ecosystem is massive but fragmented. Need state management? Choose from Redux, Zustand, Context, or 47 other options. Need styling? CSS-in-JS, CSS modules, styled-components...

Analysis paralysis is real.

3. The Learning Curve Never Ends

Hooks, Context, Suspense, Concurrent Mode, Server Components... React keeps adding complexity. I've been using React for 4 years and still learn new gotchas weekly.

What I Wish I Knew Earlier

Performance by Default

// React: Manual optimization needed everywhere
const MemoizedComponent = React.memo(({ data }) => {
  const expensiveValue = useMemo(() => 
    processData(data), [data]
  );

  return <div>{expensiveValue}</div>;
});

// Svelte: Fast by default
<script>
  export let data;
  $: expensiveValue = processData(data);
</script>

<div>{expensiveValue}</div>

Built-in Animations

<script>
  import { fade, slide } from 'svelte/transition';
  let visible = true;
</script>

{#if visible}
  <div transition:fade>
    <p transition:slide>Smooth animations, zero configuration</p>
  </div>
{/if}

Try doing that in React without a 200kb animation library.

The Migration Reality

"But what about the ecosystem?"

Valid concern. Here's what I found:

• Component libraries: SvelteKit UI, Carbon Components Svelte
• State management: Built-in stores (tiny and powerful)
• Routing: SvelteKit (better than Next.js)
• Testing: Vitest works perfectly
• TypeScript: First-class support

Real-World Results

Since switching to Svelte:

✅ Deploy speed: 3x faster
✅ Bundle size: 95% smaller

✅ Development time: 40% reduction
✅ Bug reports: 60% fewer
✅ Team satisfaction: Through the roof

The Uncomfortable Truth

React became the jQuery of 2024. Overly complex for most use cases, kept alive by momentum and big corp backing.

Meanwhile, Svelte just works.

No mental gymnastics. No performance optimization rabbit holes. No dependency hell.

Just write code that does what it looks like it does.

What's Next?

I'm not saying React is trash. For massive teams with existing React codebases, migration might not make sense.

But for new projects? Svelte every time.

The web development world is slowly waking up:

• GitHub's new dashboard: Built with Svelte
• Apple's developer docs: SvelteKit
• The New York Times: Migrating to Svelte

Try It Yourself

Don't take my word for it. Spend one weekend building something in Svelte.

npm create svelte@latest my-app
cd my-app
npm install
npm run dev

I guarantee you'll have that "holy shit" moment I had.

---

What's your take? Still team React or ready to try something new?

Drop your thoughts below 👇

Comments

[VS]

I don't agree with this. React is a mature and powerful library with a well-established ecosystem. While Svelte offers an interesting approach with its templating and compile-time optimizations, it can become cluttered in larger projects, especially when complex logic gets mixed with templates. React, on the other hand, encourages a more modular and component-based structure, and it's actively evolving based on feedback from the developer community. That kind of community-driven development is what keeps a framework alive and relevant. React isn’t going anywhere anytime soon.

[shiva shanker]

Hey VS, appreciate the thoughtful response. You're absolutely right about React's maturity and ecosystem - that's real value, especially for larger teams.
I think we just have different experiences with the "cluttered templates" thing. In my projects, Svelte's single-file components actually stayed pretty clean, but I get how it could feel mixed up at first.
Have you tried Svelte on any projects? Curious about your hands-on experience with it.
You're spot on that React isn't going anywhere. Both tools have their place - React for established teams, Svelte for faster development. Different situations, different solutions.

[VS]

Totally fair — it really comes down to the type of project and team setup. I’ve experimented with Svelte a bit (mostly on smaller side projects), and personally found that as complexity grew, it became harder to keep logic and markup clean compared to React.

That said, I definitely see the appeal — especially for solo devs or small teams looking to move fast. It’s great to have options that fit different use cases, but I still feel more at home with React for anything complex or collaborative.

[José Pablo Ramírez Vargas]

1. React has one of the slowest turnarounds on releases.
2. Unless you show me an actual example of a cluttered project that is not the developer's fault, I'll believe it.
3. How does React foster modular structure more than Svelte? Elaborate.

Yes, React isn't going anywhere soon just like jQuery is not going anywhere any time soon, but not for the reasons you describe, but because there are too many projects written in React. That's it. In today's age, where React's benchmarks are just pitiful, choosing React for a new application makes zero sense.

[Roshan]

What you’ve written really hits on why so many developers are starting to feel “done” with React. It solved real problems when it came out, but over time it’s become heavy with complexity. Hooks were supposed to simplify state management, but in reality they introduced their own set of quirks (useState not updating immediately, dependency arrays in useEffect, endless gotchas). Add on top of that the constant churn with new features like Concurrent Mode, Suspense, and Server Components, and you’re spending more energy keeping up with React’s way of doing things than building features.
Svelte flips that around because it doesn’t carry the weight of a virtual DOM or endless libraries for basics. Instead of a fragmented ecosystem where you have to pick Redux vs. Zustand vs. Context, Svelte has stores built in. Instead of spending time fighting performance issues and wrapping everything in memo, Svelte compiles down to efficient vanilla JS. The difference in bundle size and build time isn’t just theoretical it’s something you feel day to day as the app grows.
Another underrated part is readability. The example you gave with async data fetching says it all: in React, even a “simple” component often feels verbose and boilerplate-heavy, while in Svelte it’s literally a few lines. This matters not just for speed, but for onboarding new developers, reducing bugs, and making codebases maintainable long term. And then you add built-in animations and transitions that just work, without pulling in half a dozen external libraries that’s a huge quality-of-life win.
I think the biggest point is that React has become the “default” because of its ecosystem and corporate backing, not because it’s the most productive choice anymore. For existing codebases with massive teams, React still makes sense because migration cost is too high. But for new projects, Svelte (and in some cases, frameworks like Solid or Qwik) simply let you move faster and keep the codebase smaller. Companies like GitHub, Apple, and The New York Times adopting it prove it’s not just hype.
So yeah, React isn’t trash, but it does feel like jQuery in its late days widely used, still fine for many cases, but no longer the most elegant or future-facing solution. Svelte shows that web dev can actually be simpler again, and that’s why so many devs who try it don’t want to go back.

[shiva shanker]

Roshan, you absolutely nailed it. You captured so many points I was thinking but didn't have space for.
That hooks complexity thing is so true - useState async issues alone have probably cost developers thousands of hours. And the useEffect dependency arrays... ugh.
The jQuery comparison really hit home. Same cycle - revolutionary at first, then suddenly it feels heavy. React's going through exactly that.
Thanks for mentioning Solid and Qwik too. The whole "post-React" world is getting exciting - simplicity and performance are finally winning over ecosystem size.
Really appreciate the thoughtful response. This is exactly the discussion I was hoping for.

[csm]

Man, I know you are a real dev and have real projects experience, so you know how react feels!But, as a learner just switched from svelte to vue to now react and feeling it as awesome! Don't take me wrong, but for learning, react helps in understanding concepts!

[shiva shanker]

Hey csm, that's a great point actually. You're absolutely right that React is excellent for learning fundamental concepts. The explicit nature of useState, useEffect, and props really helps you understand how state management and component lifecycles work under the hood.
I think that's one of React's strengths - it doesn't hide too much magic, so you learn the underlying principles. Those concepts transfer well to other frameworks too.
My frustration is more about productivity on larger projects after you've learned those fundamentals. But you're spot on that React is a solid educational foundation. I still use both actually - React for complex apps where I need the ecosystem, and Svelte for smaller projects where speed matters more.
Since you're learning, I'd suggest really mastering these React concepts: component composition, lifting state up, and understanding when to use useEffect vs useMemo. These will serve you well regardless of which framework you end up preferring later.
What concepts have you found most helpful to learn through React so far? And what type of projects are you building?

[csm]

Thanks! Getting advice and insights from a real dev really helps a beginner like me.
Will try to learn those concepts!

Concepts I found helpful:

1. routing looks clear and simple

2. state management especially the fact that we get two separate things: the variable and the set function.

3.components need less boilerplate (plain js function)

4.And project structure is simple!

And I used react in a hackathon for creating old windows desktop clone
Although I did not do the whole part, but it was my first time using react and in 3 days we finished it!
Here is the link: devpost.com/software/temp-ufwthd

[shiva shanker]

That's awesome csm. Those are exactly the right concepts to focus on. You've really grasped the core ideas that make React powerful.
The state management insight you mentioned is spot on - understanding that separation between the variable and setter function is fundamental to how React works. And you're right about the project structure being simple once you get the hang of it.
That hackathon project sounds impressive - finishing a Windows desktop clone in 3 days shows you're definitely getting comfortable with React. I'll check out your link.
Keep building projects like that. The more you practice with React, the more those concepts will become second nature. You're on the right track.

[csm]

Thank you!

[ArtyProg]

I’ve personally switched to Juris, and I couldn’t be happier with it.

Here’s a simple example of building a 3-layer architecture application on the frontend—no bundler required. The code runs directly in the browser, as is.

I’m sharing this because it fits my brain. If it doesn’t resonate with you, that’s totally fine and comprehensible, just please avoid turning it into a heated debate

I precise that I am not the author of Juris, and I have absolutely no financial interest in promoting it.

Beware, if adopted, Juris can be very addictive, I have already experienced it.

Article

Demo

Here is the code, pure vanilla Javascript, totally comprehensible to newcomers :

    // ------------------------
    // 1. Services (pure)
    // ------------------------
    const Services = {
      fetchUsers: async () => {
        const res = await fetch("https://randomuser.me/api/?results=5");
        if (!res.ok) throw new Error("Failed to fetch users");
        return res.json();
      }
    };

    // ------------------------
    // 2. HeadlessComponent
    // ------------------------
    const UserFetcher = (props, { setState, svc }) => {
      const componentApi = {
        fetchUsers: async () => {
          setState("userState.loading", true);
          setState("userState.error", null);
          try {
            const data = await svc.fetchUsers();
            setState("userState.users", data.results);
          } catch (err) {
            setState("userState.error", err.message);
            setState("userState.users", []);
          } finally {
            setState("userState.loading", false);
          }
        }
      };

      return {
        api: componentApi,
        hooks: {
          onRegister: () => {
            componentApi.fetchUsers();
          }
        }
      };
    };

    // ------------------------
    // 3. UI Components
    // ------------------------
    const Skeleton = () => ({ div: { className: "skeleton" } });

    const Card = (user) => {
      const { name, picture, login } = user;
      return {
        div: {
          className: "card",
          'data-user-id': login.uuid,
          children: [
            { img: { src: picture.thumbnail, alt: `${name.first} ${name.last}` } },
            { h2: { text: `${name.first} ${name.last}` } }
          ]
        }
      };
    };

    const EmptyState = () => ({ div: { className: "empty-state", text: "Click the button to load new users!" } });

    const ErrorState = (msg, ctx) => ({
      div: {
        className: "error-state",
        children: [
          { div: { text: `⚠️ ${msg}` } },
          { button: { text: "Retry", onclick: () => ctx.UserFetcher.fetchUsers() } }
        ]
      }
    });

    const renderContent = (ctx) => {
      const { users, loading, error } = ctx.getState("userState");
      if (error) return ErrorState(error, ctx);
      if (loading) return Array(5).fill().map(Skeleton);
      if (users.length === 0) return EmptyState();
      return users.map(Card);
    };

    const App = (props, ctx) => ({
      div: {
        children: [
          { h1: { text: "JurisJS Random Users" } },
          {
            div: {
              className: 'content-area',
              children: () => renderContent(ctx)
            }
          },
          {
            button: {
              text: () => ctx.getState("userState.loading") ? "Loading..." : "Load More Users",
              disabled: () => ctx.getState("userState.loading"),
              onclick: () => ctx.UserFetcher.fetchUsers()
            }
          }
        ]
      }
    });

    // ------------------------
    // 4. Bootstrapping Juris
    // ------------------------
    const app = new Juris({
      services: { svc: Services },
      headlessComponents: {
        UserFetcher: { fn: UserFetcher, options: { autoInit: true } }
      },
      states: {
        userState: {
          users: [],
          loading: false,
          error: null
        }
      },
      components: { App, Skeleton, Card, EmptyState, ErrorState },
      layout: { App }
    });

    app.render();

    app.enhance(".card", (ctx) => ({
      onclick: (e) => {
        const userId = e.currentTarget.dataset.userId;
        const users = ctx.getState("userState.users", []);
        const user = users.find(u => u.login.uuid === userId);

        if (user) {
          alert(`Hello from ${user.name.first} ${user.name.last}!\n(Email: ${user.email})`);  
        }
      }
    }));

[shiva shanker]

ArtyProg, thanks for including the live demo - seeing it in action really helps understand what you mean about Juris being addictive.
The code-to-result ratio is impressive. What strikes me is how readable the whole thing is - even someone new to the framework could probably follow the flow from services to state to UI pretty easily.
The no-build-step aspect is refreshing too. Sometimes you just want to write code that runs directly in the browser without waiting for webpack to do its thing.
I'm curious about how it handles more complex scenarios - like deeply nested state updates or performance optimizations for larger lists. But for this use case, it definitely looks clean and straightforward.
Might give it a try on a side project. Thanks for sharing the practical example rather than just theory.

[ArtyProg]

Thank you very much, for your kind reponse.

The only thing I can say, it's try it for your side projects , that is the only way you will really appreciate it.
I can assure you, you will never have bad experiences managing states with Juris :-)
Futhermore Juris include FSM (ffinite state machine), the only way to manage complex forms states

Meanwhile you can look at those single pages no bundling, examples :
(Copy the source page, and you can instantly run them :-))

My personnal first project in Juris I am currently working on :
GenImage

Simple Ecommerce Demo by Resti
Ecommerce

Kanban by Resti
Kanban

Resti Demo
CodePen Examples

Doc Juris by Resti
Wiki

Here is the roadmap of Juris :

I let you discover many more on Juris site :-)

Regards

[OssiDev]

Svelte has way more opinions than most UI frameworks, which is why it's suitable if you accept their approach of more server-side rendering, but I found Vue to be a great middle ground and so much better than React. I tried Svelte but for me it was too opinionated.

[shiva shanker]

That's a fair point about Svelte being opinionated. Vue is definitely a solid middle ground - I actually used Vue before React and really liked it. The template syntax felt natural and the learning curve was much gentler.
What specific opinions in Svelte felt too restrictive for your use case? Always curious to hear different perspectives on framework trade-offs

[José Pablo Ramírez Vargas]

You can do Svelte fully on the client side. SSR is contained purely in Sveltekit. You can do Vite + Svelte, and it will be full CSR.

[Juanda Martínez]

I've been working professionally with React over the last 5 years, I feel your pain dealing with all this complex stuff that only keeps growing over time, but let's be real; It is a privilege to choose not using React anymore, it will depend on everyone's context we are living.

I guess your point of view is coming from an indie developer who can try new stuff as they please. But for other people, there's no much choice if our "easy" way is to stay in a 9-5 job, the market is either choosing React or Angular, some opportunities come with Vue, but not much room for Svelte, so we need to stick with these standards.

I know it shouldn't be like this, but if you are not a founder or a solo dev, you need to keep grinding your React skills, and learn those over complicated topics, which most of times you don't need to worry about until there is an actual performance issue. At the end companies only care about their product to work and make money.

With this I'm not saying that I disagree with your post, I just wanted to share another perspective. I've been looking forward to learn Svelte though, I guess by reading this post encourages me to finally give it a shot!

[shiva shanker]

You're absolutely spot on, Juanda. You've captured the reality perfectly - most of us don't have the luxury of choosing our tech stack. I'm fortunate to work on projects where I can experiment, but I totally get that the job market is heavily React/Angular focused.
I still use React for client work and team projects for exactly the reasons you mentioned. Companies need developers who know the stack, and React skills pay the bills.
Definitely give Svelte a try on a weekend project though, Even if you can't use it professionally right now, it's great for understanding different approaches to reactivity.

[Aleksei Berezkin]

The comparison is not very fair. The main difference is that React executes effects in the next “tick” after render, while Svelte does this immediately. This means, the app may re-render before some effect / event handler finishes, which may accidentally cancel some other effect waiting up the tree. In practice this means that every effect changing the state have to be coupled to other effects. Does it really simplify things? Not sure. Virtual DOM is not free, and you are right that it's somewhat hard to master, however it solves some hard problems impossible to solve otherwise.

UPD React + Redux is about 200 kB (minified). Seems your number is a bit exaggerated 😉

[shiva shanker]

Thanks for catching that, You're absolutely right about the React + Redux size - I should've been clearer about including additional project dependencies.
Good point on render timing too. Both approaches have their trade-offs. I still reach for React when I need its ecosystem or working with larger teams, but Svelte's immediacy works well for the projects I'm building solo. Different tools for different situations.

[Matti Bar-Zeev]

Totally agree, and I would try SolidJS before Svelte since the mental model of development remains quite the same (jsx, etc.).
The main issue, as I see, it is that when a company "bets" on a technology, one of the main concerns is the ability to hire developers who master that technology. React has a strong grip on the FE dev community, and it's relatively easy to find devs for it, while SolidJS, Svelte or whatever are much harder to find developers for

[shiva shanker]

Great point about SolidJS - the JSX familiarity definitely makes the transition easier. You're spot on about the hiring challenge. That's honestly one of the biggest barriers to adopting newer frameworks, even when they're technically superior.
It's a classic chicken-and-egg problem. Companies stick with React because developers know it, developers learn React because companies use it. Breaking that cycle takes time.

[Chinmay]

I for one also like to use Svelte, I like to promote it too, just like you, but what if someone has no choice but to work with React ? For example working with a pre-existing codebase, or need to refactor some functionality within it,

My biggest learning is not to intertwine state with React at all, not to rely on useState() hooks at all, might seem counter productive, but this is the way for React.

React should be treated purely as a view library and nothing more than that, I would probably end up using some fine reactivity libs to handle state in React apps, if I had to refactor some codebase and schedule re-render based on updated values, for example I am better off using Valtio and be in complete control of the state of the app, rather rely on useState(), useReducer() and be shocked when there are unnecessary renders and what not.

React is not reactive at all, we would want to add true reactivity with these state libs like valtio, jotai, zustand etc,....

[shiva shanker]

That's actually a really smart approach. Treating React purely as a view layer and handling state externally with libraries like Valtio or Zustand definitely reduces a lot of the React-specific headaches.
You're right that React isn't truly reactive - it's more like a state-to-view mapper. Using proper reactive libraries for state management while keeping React for rendering makes a lot of sense, especially when you're stuck with existing codebases.
I still use React this way for larger projects. The framework choice really depends on the context - existing codebase, team size, project requirements. Thanks for sharing that perspective

[component directory]

This resonates so much! I’ve spent years navigating React’s ecosystem, and the constant juggling of hooks, context, and state management libraries can feel like more work than actually building features. Your Svelte examples really highlight how much cleaner and readable the code can be, especially for things like async data handling and reactive updates.

The performance gains and bundle size reduction you shared are staggering, it’s one thing to hear about them, but seeing numbers like 847kb → 23kb and build times dropping from 45s → 3s really drives it home.

I’m curious though, for teams working on larger applications with multiple developers, do you think Svelte’s simplicity scales well, or do you hit other challenges when the codebase grows?

Either way, your post is a strong reminder that sometimes the best tool isn’t the most popular one, but the one that lets you actually enjoy building.

[shiva shanker]

Thanks. Really glad the examples resonated with you.
For larger teams, I think Svelte scales well in terms of code maintainability, but you're right to ask about challenges. The main issue I've seen is the smaller ecosystem - sometimes you need to build things from scratch that have ready-made React solutions.
Also, onboarding can be slower since most developers know React hooks but need time to learn Svelte's reactivity patterns. For established teams, React might still be the safer choice. But for new projects with flexibility? Svelte's been fantastic