React.js has been my go-to framework for years. I’ve built countless projects with it, from tiny prototypes to enterprise-level apps. It’s been a journey filled with learning, late-night debugging, and the satisfaction of shipping great features. But here in 2025, I’ve made a decision: I’m stepping away from React.
This isn’t some “React is dead” rant (spoiler: it’s not). It’s more like a reflection on why the framework that once felt indispensable now feels like a weight I don’t want to carry anymore. If you’re a React dev or someone deciding whether to dive into it, let me explain my reasoning.
The Ecosystem Fatigue Is Real
React’s ecosystem is huge, and for years, that was its biggest strength. Need a router? React Router. State management? Redux, MobX, Zustand, or Context. Want server-side rendering? Hello, Next.js. But over time, this "choose your own adventure" style started to feel more like a maze.
Building a simple app often means cobbling together a dozen libraries, each with its own quirks and updates. You spend more time managing dependencies and figuring out how tools fit together than actually solving the problem you set out to tackle. It’s exhausting, and honestly, I’ve had enough of it.
React Isn’t Simple Anymore
Remember when React was all about simplicity? Back in the day, you wrote class components, passed some props, and called it a day. Then hooks arrived—and they were awesome—but they also came with their own complexity. Suddenly, every blog post and tutorial was about managing useEffect dependencies or battling React’s rendering lifecycle.
And don’t get me started on server components. They’re supposed to make things easier, but they add yet another layer to an already complicated stack. At some point, React started feeling less like a “library for building user interfaces” and more like a convoluted framework trying to be everything at once.
The Market Is Overcrowded
If you’ve been job hunting recently, you’ve probably noticed that React is still everywhere. That sounds like a good thing, right? Plenty of jobs, lots of demand. But the reality is that everyone and their dog knows React now. The market is so saturated that standing out as a React developer has become incredibly hard.
Meanwhile, newer frameworks like Svelte and Solid are carving out niches where demand outpaces supply. Learning them feels like investing in a smaller, less crowded pond where you have a better chance of catching a big fish.
The Alternatives Are Just Better
Over the past couple of years, I’ve dabbled in frameworks like Svelte, SolidJS, and Qwik, and honestly? They’re a breath of fresh air. They’re simpler, faster, and often more intuitive than React.
Take Svelte, for example. No boilerplate, no useState, no useEffect. You write what you mean, and the framework takes care of the rest. It feels like coding in React’s early days, but without all the baggage that’s piled up over the years.
Or look at SolidJS—it’s like React on steroids. It uses the same component-based architecture but with better performance and smaller bundle sizes. And then there’s Qwik, which is rethinking how hydration and rendering work entirely. These frameworks are innovating in ways that make React feel… old.
The Community Shift
The React community has always been one of its strengths, but even that’s started to change. With so many tools and libraries in the ecosystem, the community feels fragmented. Everyone has their own “best practices,” their own stack, their own way of doing things. It’s harder to find a shared sense of direction or even solid advice that works universally.
Meanwhile, communities around newer frameworks feel more unified. They’re smaller, sure, but there’s a sense of excitement and collaboration that reminds me of React’s early days. It’s invigorating to be part of something that feels fresh and full of possibility.
React Is Still Good… Just Not for Me
I want to be clear: React isn’t bad. It’s still an incredible tool for many developers and projects. If you’re working on a large app with an established React codebase, there’s no reason to rip it out. If you’re just starting your journey in web development, React can teach you a lot about modern front-end practices.
But for me, it’s time to move on. I want simplicity. I want to spend less time configuring my stack and more time building things that matter. I want to explore frameworks that feel designed for 2025, not 2013.
What’s Next?
I’m doubling down on Svelte and SolidJS. They align with what I want out of my tools: speed, simplicity, and innovation. I’m also keeping an eye on Qwik and frameworks like Astro, which offer exciting new ways to think about web development.
If you’re still using React and loving it, that’s great. But if you’re feeling frustrated or burnt out, know that there are other options out there. Explore them. Play around. You might find something that reignites your passion for coding.
What about you? Are you sticking with React, or have you started exploring alternatives? Let’s talk in the comments.
Top comments (156)
Every discussion I read about front-end frameworks focuses heavily on state management, learning curve, and performance. But almost no one mentions core features that must be found in the framework, like...
FORMS. How do you manage forms (their state, validation, logic for complex forms) with Svelte, Solid, React, Vue, etc? Angular has an AMAZING
@angular/formspackage. Forms are the core of all enterprise-grade applications. What frameworks mentioned above can offer to developers?DI (dependency injection). How do most popular frameworks manage dependency injection?
Angular is a framework. It's mature and complete. We are now in 2025, faster computers and It's being a long time I don't see "performance issues".
Learning curve? well, If you are a good software engineer you'll see that angular uses patterns and it's kinda natural to use them. Maybe this divide the juniors from seniors. Anyone can write poor react, vue, bla bla code. In angular, otherwise, you can find some better code.
Yes, after 25 years in this industry I saw that Angular was one of the most stable and mature solutions created for frontends and webapps.
By performance issues i mean web vitals - everyone is now trying to catch '100' points for each score. I might be unclear on that item
I agree that you can write poor code with any framework/library. What I love about Angular - you switch the project with completely different team/company - you'll see the same patterns, set of libraries and same solutions. Oh another point i love about Angular - migrations are mostly easy - don't have to struggle with the updates from version to version - in most of the cases simply run command to migrate
Hi Ilya, Great question! For forms, React doesn’t have a built-in solution like Angular’s @angular/forms, but libraries like React Hook Form and Formik are very powerful, offering declarative APIs and excellent validation support. For DI, React relies on Context API for dependency sharing, but it’s not true DI like Angular’s system. Alternatives like InversifyJS can help if you need a more robust DI pattern in React. Svelte and Solid handle forms with minimal boilerplate due to their reactive nature, but you'd need libraries for advanced scenarios. For DI, these frameworks don’t natively support it, but patterns using context/providers can mimic the functionality.
Thank you for your reply! That's the point of my comment - many frameworks don't offer standard packages for core functionality that is a core of many apps these days (name web app without form, router; just as an example 😄). And I guess there will be a delay in those libraries' updating when a new framework version is released? Migration from one library to another brings lots of headaches, and, again, as mentioned in your post... fragmentation - each project is unique and will have its own set of libraries. Choosing a framework these days is similar to choosing the country to live in if you're not happy with the current one 🤣
Another good point I would mention in your article - is how easy it is to migrate from one version of the framework to the other - will it require an hour, day, or week in case of big breaking changes? 😎
Form hook yes, Formik it's performance pain
Bro, this is a React crowd, you're talking to a wall here. They don't get DI nor OOP 😂. But for the record, I agree.
Vue is pretty close if you use either a well known UI library (PrimeVue, maybe Vuetify) or a well know library like Vee-Validate.
Svelte sort of has a philosophy of getting back to using native HTML, native UI futures, etc. which is nice, but because of that, there's no first party form handling library. SuperForms is emerging as a contender for that framework though.
I've played with Vue 2 before - it was great, to be honest! But at that time it didn't have forms package (nor built-in, nor 3rd party). Formulate was on the horizon, but was unstable. And then Vue 3 was announced and then released and migration was a pain for all (?) projects and libraries? But apart from that issue - i think Vue is great!
I've used SvelteKit recently - I liked it (as to me, looks closer to Vue 2 (since i haven't tried Vue 3), than to any other library), but i'm not sure i would use it for some BIG (enterprise-grade) project
I mean yeah it really depends on what the requirements are. I suspect form-heavy features with elaborate validation rules. There's definitely a need for that in the Svelte world, SuperForms aside. I do also think that while SvelteKit is fantastic, the philosophy of sticking to native HTML and browser APIs may be cumbersome if you want 1st party components like select fields with custom option components, date pickers, and data tables.
I've been an angular developer for years and it's funny and sad at the same time how it never gets the credit it deserves sometimes.
You are right in that "every" article talks about the "wrong" things - but angular does NOT have an "amazing forms package".
For one it's typing is - paradigm bound - much worse than the alternatives in reacts ecosystem (largely due to how inference currently works).
But mostly because, if you think about it, its the same "state management issue" rehashed into an import.
WHY would you even want to explicitly sync the DOM state into an "explicit" object that is often spread out across a component tree that yet again mimics the DOM tree and every so often brings up conceptually unsolvable syncing issues?
Where does the need come from to have a way to say that a property on an object violates some constraint - that is at best a rebranding/predecessor of the Constraint API - based on a dozen other properties from that same object just to hope that the framework will then take core of stuff like preventing submits and marking fields as invalid when you could just set the damn attribute on the damn element and let the browser take care of it?!
You say forms are at the core of every enterprise app and yes, I agree. They are also at the core of the browser. Stop translating everything into JSON by default without knowing about "the old ways" of simply writing a trivial form tag.
Oh and btw, that doesn't even mean you have to give up on type safety, not when it matters at least.
@hesxenon
Unfortunately, it is not always easy to implement the logic that the business is asking for with the DOM API for accessing form elements, FormData API for working with form data, and Validation API for form validation in a convenient way and without spending a lot of time on it.
I believe Angular Forms has key benefits including two-way data binding, which automatically synchronizes model and view, and a robust built-in validation system with both synchronous and async validators.
Angular provides comprehensive form state tracking and error handling through Reactive Forms, offering superior TypeScript integration and testability.
Do you have similar solutions in React to achieve the same functionality?
Angular Forms comes with all the necessary features out of the box.
Angular also includes nested forms support, form arrays for dynamic forms, and the FormBuilder service.
Everyone chooses a tool that is convenient and understandable to them. The choice of tool should still depend on the specific requirements and limitations of the project.
But my choice is Angular if I am making a site or service more complex than a regular landing page with a form for submitting an application.
Angular forms are amazing! I work with them almost every day. And our forms are complex, it's not about comment or contact us form - they have lots of logic (i'm not talking about validators). Talking about validation - validation attributes can't cover even big portion of the things we need. Building native validators with attributes (custom, not just by by pattern) are complex thing and it works with DOM anyway. When then re-invent a bicycle every time? Framework is made to ease the pain. Isn't it?
Yeah, I'm talking about complex forms too. Forms with sometimes hundreds of fields that are interlinked in non-trivial ways. But in the end there arw always only two cases: either you do simple constraint based validation in the frontend or you ask the server because you rely on data that isn't available in the FE. Both of these things are easy to do without relying on angular forms.
You do realize you can change constraint attributes and that the constraint api blocks submissions accordingly?
Also, I find it kinda funny when people say "why not use a framework/library instead of reinventing the wheel" when that approach is exactly reinventing the wheel.
Just try building a complex form with the constraint/formdata api instead, all you need is component associated state and knowledge about the two apis in question. You'll see that with a bit of brainpower you can circumvent many of the angular/forms problems that come up
For Svelte, people love Superforms.
Oh! Good to now there is some solution for Svelte. Thanks!
The reason react doesn't have core packages was trying not to be too opinionated, light weight focus on the UI itself. Which seemed good at the time but feels like a it's something we could do with now they're are in 900 form libraries
It's incorrect to compare react with angular in general. it's more about comparing nextjs (or any other framework based on react) and angular
Forms are simple stuff! What's the big deal with them?
When you deal with complex forms with multiple steps, state/value validation and logic when several fields depends on the values of other fields
Does angular still use the nx attributes of html to bind things? That's what our me if originally
you mean
ng? yes, angular still use attributes to bind things, but not all of them areng- it's rare nowBecause React it's library, Angular framework.
I do understand the difference. But what percentage of all projects with React (as a library) are developed without any framework solution? I know it doesn't make sense to compare react with angular, but nextjs and angular is proper to compare. And i guess when many developers mention react - they mean some framework based on react
Dont go being so practical now. Leave some room to profess your technical prowess over the next developer with your knowledge of the latest hook and library.
Welcome aboard. I cannot say I went through the same realization because I'm a long-time back-end developer. I came to know React and more UI work in 2020, and in 2023 I became the team leader. By 2024 I had done research and selected Svelte as its replacement.
For anyone wanting to get out of React or Angular, but don't know how: The answer is micro-frontends. No matter how small your development team is or how big your application(s) is(are). You can always migrate by steps using something like
single-spato do pieces progressively until you are fully migrated.Is micro-frontend not a buzz word for modular architecture?
Microservices in the backend are an over-engineered solution for most sites. Moving this idea to the frontend requires more code to load in the browser. Because if you want to do it right you need a message system, monitoring, security and so on.
You clearly are speaking without a single shred of information or experience. A messaging system is not necessary, but if you must, there's Broadcast API, security is already set up if you come from an existing project, and "so on" is probably already covered.
I have personally led the conversion of a 100% React code base to Svelte. We have 2 MFE's in Svelte v4 and 2 in Svelte v5. Our setup has been carefully planned and requires no messaging system: We do all with component props, native ES modules that we use as utility modules, and
single-spa.To give you an idea, a React MFE can prompt the user with an overlay made in Svelte by simply importing a function from a utility module:
import { systemOverlay } from '@app/root-service';. That's it. This works. No magic anywhere else. No messaging system. Nothing but a normal import.True I have no experience with micro-frontends. But I have experience with microservices. My comment was from that point of view.
The messaging system Is not always needed, but in some cases the services need to communicate with each other. I guess in your case the solution was setting component props at runtime?
The monitoring comes in to play if you run the micro-frontends in different processes or on different servers. If the process/server goes down for some reason the app must have a way to react in that case. It requires more code than when you have a monolith.
If you do the micro-frontends on a different process/server. each is responsible for the security of their endpoints. So i find it a bit strange you mention that the security of the react code can be used as is?
That is why I specified if you do it right, meaning porting the microservice architecture to the frontend one on one.
I don't believe many people do it like that, and that is the base for the modular architecture remark.
The biggest problem for me with micro-frontends, is that it is more likely to load multiple frameworks. In your case react, svelte v4 and svelte v5. Svelte has a small framework footprint, but what if teams decide to use Angular, Vue, or something else.
On the backend that is not a problem because code is not loaded to the browser before execution.
Your main problem relies on the fact that you try to port microservices to micro-frontends. They share the name significance because they are similar if seen from a distance. When you get closer, micro-frontends have important diferences. The most important one is that all micro-frontend code shares the same process and address space, no matter the origin. This doesn't happen in microservices, where you have (usually) entirely different virtual servers.
Communication
Yes, a messaging system works, but it depends on the data to be serialized, so this is the most primitive and less useful. Still, browsers have the built-in system named Broadcast API.
Since all code share the same process and address space, the most versatile methods are to pass props and to import code. This is where a library like
single-spahelps. With this library, we can pass props from Svelte to React or the other way around. Still, this means that the data/code passed is only available after the component mounts. This brings me to the next solution.Utility modules are the most versatile and consistent. They let you import code, and that code comes (if you so wish) from another micro-frontend. For example, our application still has the top-level MFE that authenticates in React. This guy authenticates and then provides as an exportable function, a customized
fetch()function that other MFE's use. This function is capable of obtaining and renewing tokens.The latter comes with a trade-off: One has to code the module as if it were an isolated NPM package, or imports can get circular.
Monitoring
It is no different to monitor a microservice or any other server. I don't see the point of bringing it up. Goes down and UI must have a way to react? This is no different to consuming microservices that can go down as well. I also fail to see why this is mentioned. Is it because it requires more code? Sure, nothing is free. Setting up MFE's comes with a cost.
Security
You seem to be thinking that MFE's need security on the server. Most of the time this is not the case. Most of the time, the code is allowed to be downloaded anonymously, as you should have zero secrets in the client. All security should be placed on the API side. However, if one must secure something, it is the same as securing any other HTTP server. Pick your server technology and work from there. It has no relation to MFE's.
Multiple Frameworks
Well, it is their fault for choosing the loser. This has nothing to do with MFE's and everything to do with the (bad) frameworks you choose (React, Angular and a few others). We're using MFE's to get rid of the bad React choice, and we're very pleased with the results.
So what you are saying here, that is for me modular architecture.
And that removes a lot of concepts coming from the microservices context.
I guess we had a discussion based on bad naming of a concept :)
Microfrontends can be good solution if your app is huge as well as the team behind it. I was looking into it, used it in one project, but i'm not ready for another project with microfrontends. Yet
For an app to be huge or the team to be huge are myths. Truth is: MFE's can be used to migrate technologies little by little, regardless of app or team size.
The main goal of MFE is not migration of the technologies
Correct, but it can serve as a migration tool. We are only 3 devs and we use it like this, quite successfully.
This perfectly describes my experience. Learning react is too much about how not to use it. I instinctively started using SolidJS as soon as I found it. So far it feels pretty ergonomic. But it is shocking how accepting the web community is of bad tools and the bad engineering that follows. Coming from any other platform is shocking. It makes me think... You all live like this?
Hehe, me too! For example, I cannot believe people are happy with
dotenv. Like, come on! This is just a bunch of flat files and the concept of environment doesn't even exist in the browser. All is artificial.It's the same with React. It's slow, bad, confusing, and complex, and yet people still think it's the go-to library for UI development. Sheep mentality, I suppose.
I have learned professionally that most people will accept their circumstances and not worry about if things could be better. It drives me insane because people like you and me are the minority. In a work setting where you need people to get on board, we're considered complainers.
As for dotenv, I don't have an issue with it. I find it to be a convenient setup if not abused, and some environments are building support for it in directly.
Being a .Net developer, coming to know
dotenvfelt like a huge downgrade.How so? I haven't had the opportunity to do much with .Net
.Net's configuration system is superb. You'll see if you ever learn .Net.
I totally agree with your points on React! That's the reason why I chose to switch from react to Vue—it’s simple, easy to learn, and very readable. Despite its simplicity, Vue still offers the features and flexibility needed for professional development. It’s a great balance of being beginner-friendly while also powerful enough for larger projects.
I find Vue much simpler than React. At first I thought the main difference for me was the structure of the file with vue having clear template and logic, with react lucking it, but then it kind of blurred as there is still that "return" statement that makes your template.
I was surprised when I learned a video hosting company using it for their front end.
Even though I am primarily a back end engineer, getting my hands dirty with FE was a pretty good idea. The amount of frameworks on the market provides a good pool to choose from. Going to check SolidJs next, it's been suggested here.
New tech is always good, so we are not sitting duck and of course each library and framework will have followers that don't like the other frameworks. :)
Your frustration is my frustration. I’m so aggravated and can’t take it anymore.
I blinked and my app was ancient.
I had react 18.30 and now it’s 19. My MUI version is now deprecated and I only installed it 6 months ago.
Same with file saver , react router dom, docxtemplater and ag grid.
It’s impossible to keep up.
I’m out here working hard to make great applications meanwhile some bored devs somewhere who have nothing to do with there lives spend there time making sons new hooks and forcing me re learn all documentation I learned already and break my app
Great write-up, and I appreciate how balanced you kept it — you were clear that React isn't "dead" and that it still works for many people. I'd push back on a few points, though.
On "React isn't simple anymore": I think this conflates React the library with the surrounding tooling (Next.js, data libs, etc.). Plain React with hooks is arguably simpler today than class components ever were. The complexity people feel is usually the ecosystem you layer on — and that's largely optional.
On ecosystem fatigue: that same "maze" is also a strength — you pick tools that fit your project instead of inheriting the framework's opinion wholesale. Simpler frameworks make more decisions for you, which is great until you hit the one decision they didn't make.
On the saturated market: React's ubiquity is also why so much tooling and so many jobs exist. Being a good React dev still stands out — the market being crowded only makes it hard if you lack depth.
On alternatives being "just better": better almost always depends on context — team experience, codebase age, hiring pool. A faster new framework can be worse for a team already living in a mature React codebase.
Not trying to change your mind — exploring Svelte/Solid is a perfectly good call. Just pushing back on the framing that newer automatically means better. Curious what your first real Svelte project will be.
I really dislike these types of articles because they exhibit a lack of experience. I've worked with frontend technologies for almost 20 years. Scriptaculous, MooTools, jQuery, Dojo, Backbone, Angular, Polymer, React, and many more. Using a framework in an enterprise environment means that it has to be stable and well supported.
Oh where are the times of Scriptaculous, MooTools and Dojo.
I went more into backend development around the time Angular and React popped up. But I still follow the frontend changes, because I feel as a web developer you need to know the full stack to get to the best experience for developers and end users.
I'm amazed at how much code we were willing to let the user load in their browser, when we didn't get punished by search engines.
I think with the new wave of backend javascript frameworks and the html-first idea, developers are back on track about the purpose of javascript. In my opinion javascript in the browser is only there to enhance the application.
I think it is crazy html-first and island architecture are terms they had to invent to get people onboard with the new javascript solutions. This is how we did progressive enhancement when there were barely any frameworks or libraries.
I agree that in any company stability and support are a big factor when picking software solutions. But who says those new frameworks don't meet that threshold?
Scriptaculous & MooTools. It's been years since I heard of those.
What if the framework of your choosing complies with all these, but only because there was nothing better before? What if, for years, that framework had no decent competition? What if that had already changed?
I work for Intel. They have a list of approved and banned technologies. Still, they are open to new things. I got approval for Svelte after a very convincing presentation I made where I pretty much destroyed React.
Please share the details of that presentation. I need to destroy Nextjs in favour of Angular 😆
I'm unsure if Angular could destroy React. Svelte was EZ: Top performer, simple code, fastest signals in existence, etc.
I'm sure 😎
Thanks for sharing such a thoughtful reflection — I appreciate the honest, balanced tone. I'm one of those who still reaches for React every day, so I wanted to offer a slightly different perspective.
A few of your pain points resonate deeply (yes, the ecosystem can feel fragmented, and the "choose your own adventure" complexity is real). But I'd gently push back on a couple of points. The fragmentation is also what makes React so adaptable — there's a well-tested library for almost every need, which is a genuine asset on large enterprise projects where the "unified" approach of a full framework can become equally constraining.
On the market point: the saturation you found frustrating is, for a lot of us, the whole draw. Hiring is easier, onboarding is smoother, and the talent pool is deep. That's a feature, not a bug, for teams and businesses.
And honestly, I think every framework has a season. Svelte and Solid are genuinely exciting, and I'm glad they're thriving — good tools benefit everyone. I just don't think React's complexity is a sign it's past its prime; it's the natural cost of breadth and sheer adoption. Different strokes for different teams.
Either way, best of luck with the Svelte/Solid journey — I hope it reignites the passion you're looking for!
Why didn't you consider Nuxt?
I have previously worked with Nuxt and although it is good, this year I am looking to experiment with new technologies and stacks.
I think you should check out Cradova and get a grasp of it.
github.com/Uiedbook/cradova
Great article, and I appreciate the honest reflection. I'd respectfully push back on a couple of points, though. The "ecosystem fatigue" you describe is exactly why React has stayed so relevant—that freedom to pick the right tool is a feature, not a bug. And the so-called "complexity" (hooks, server components) isn't bloat; it's React maturing to solve problems that class components couldn't. On the market point, saturation actually means stability: the huge talent pool and hiring demand are why companies rarely regret choosing React. Svelte, Solid, and Qwik are exciting, and exploring them is healthy. But "excitement" in a smaller community often comes with trade-offs in ecosystem maturity, hiring options, and long-term stability that matter in enterprise work. For solo devs or greenfield side projects, sure—try them. But for teams shipping production software, React's ecosystem and predictability are still a huge advantage. Glad you found what energizes you, but I think React's "weight" is also what makes it dependable.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.