DEV Community

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

shiva shanker on August 18, 2025

The framework that promised to simplify everything just made my codebase a nightmare TL;DR: After 4 years of React development and bu...

Read full post

VS • Aug 20

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 • Aug 21

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 • Aug 23

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 • Sep 1

React has one of the slowest turnarounds on releases.
Unless you show me an actual example of a cluttered project that is not the developer's fault, I'll believe it.
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 • Aug 19

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 • Aug 21

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 • Aug 20

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 • Aug 21

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 • Aug 21 • Edited

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:

routing looks clear and simple
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 • Aug 21

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 • Aug 21

Thank you!

ArtyProg • Aug 20 • Edited

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 • Aug 21

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 • Aug 21 • Edited

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 • Aug 22 • Edited

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 • Aug 24

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 • Sep 1

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 • Aug 22

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 • Aug 24

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 • Aug 22 • Edited

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 • Aug 24

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 • Aug 22

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 • Aug 24

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 • Aug 23

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 • Aug 24 • Edited

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 • Aug 22

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 • Aug 24

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

The unknow • Aug 22

I am looking for a beginner or amateur developer to share my ideas for creating companies with new concepts adapted to the future and artificial intelligence.
Please write to me or reply to my comment so we can get started.
You never know, we might be the next Jeff Bezos in 20 years.

The unknow • Aug 22

shiva shanker • Aug 24

Thanks for reaching out, I appreciate the entrepreneurial spirit, but I'm pretty focused on my current projects right now.
Plus, I've noticed Jeff Bezos doesn't have much hair left - and I'm quite attached to mine 😄 I prefer keeping my stress levels (and hairline) intact for now.
Best of luck with your AI ventures though - there's definitely a lot of exciting opportunities in that space

Luigi Morel • Aug 23

If you're still getting frustrated by useState use, it's definitely a skill issue.

shiva shanker • Aug 24

Fair point, Luigi. I've definitely gotten more comfortable with useState patterns over time. Maybe 'skill issue' is harsh, but you're not wrong that experience helps avoid the common pitfalls.
I guess my point was more about developer experience - even experienced devs can hit useState gotchas, and Svelte's approach just feels more intuitive to me. But React definitely becomes smoother once you really know it

Baudouin Van Humbeeck • Aug 22

How about Django or Astro or other frameworks ?

shiva shanker • Aug 24

Django is fantastic for full-stack development - I actually use it for backend APIs. Astro is interesting too, especially for content-heavy sites where you want minimal JS.
I think the choice depends on your project type. Django for data-heavy apps, Astro for static/content sites, Svelte/React for interactive apps. Each has its sweet spot

Werliton Silva • Aug 23

Nice post

shiva shanker • Aug 24

Thank you Werliton, Appreciate you reading it.

Scope Research • Aug 22

Thanks for the tips and ideas

shiva shanker • Aug 24

You're welcome, Glad you found it helpful

Muhammed Sabith • Aug 23

I dropped react, mostly because , when I went all in Next.js , I forgot 70% of react. Now I hate it. Because Next.js has good routing too.

shiva shanker • Aug 24 • Edited

Haha, that's actually a common experience. Next.js abstracts so much that you can forget vanilla React patterns. The framework lock-in is real - you end up thinking in Next.js terms rather than React terms.
I still use both depending on the project, but I get why that experience would be frustrating

vapow • Aug 28

Really appreciate your honest take on React fatigue. I've been wrestling with similar thoughts lately - the constant updates, the complexity creep, and honestly the mental overhead of managing all those hooks. Your point about Svelte's simplicity really resonates. Have you found the transition difficult when working with teams who are heavily invested in the React ecosystem? The performance gains you mentioned are intriguing, but I'm curious about the learning curve for developers coming from years of React thinking.