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 j...
For further actions, you may consider blocking this person and/or reporting abuse
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
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 :)
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.
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.
I used to be a backend developer. In 2020, I was working with a company and started with angular and what i hated most is NgModules declaration for a new frontend dev this is pure illogical import statement i have seen, first import the component provide it to
@NgModulesdo thedeclaration,imports,providersetc. Also the file structuredir/component.css,dir/component.html,dir/component.ts. You can write three things in one when you write in basiccomponent.html.Afterwards this I started using svelte in 2021(Self learnt) and at that time few companies were using but that was not the case for India but I still took the risk and learnt the basic structure and working with that i started doing small project (Fun project to solve my own issues and day to day management of finance as per my requirement). At this same time
sveltekitwas in alpha release Idk but i started using it. I was hired by a startup in India which game me freedom to choose a framework for an internal project and I usedsveltekitand it still runs in production with:I didn't feel the requirement of multiple packages or anything extra, did face some issues with complex reactive states but I think they are fixed in v5. Now I'm working with another start up based in Paris and they approached me first because of my svelte and sveltekit work. I'm currently working with them and till now when it comes to libraries I haven't faced any issues because every package written in JS and meant to be used in browser works perfectly in svelte. With this trend I can say companies going to adapt svelte a lot and same goes for
Vuewhich can be seen in State of JS 2024.Svelte is being is in a lot of new project within top companies Apple Music is one of those examples. People sees that react is being is used height reason 10 year ago there were only two backed frameworks/library
AngularandReact, for obvious reasons they started using them and when you start using a frameworks/library you wanna stick to that which is easy for a company and they can ask a dev to switch between projects if required. Same thing is going to happen in next 10 years new startups uses new frameworks/library likesvelte,solid(I haven't used it in production but solves the complexity introduced by React. Also they introduced Signals to JS frameworks - after knockout),Vue.Things I love about Svelte:
You can check svelte project that I have stared over the period: github.com/theetherGit?tab=stars
It's there for a reason: dependency injection. If you build big applications - you'll love it...
...Angular v19 is out and how it's using standalone components, so you can start writing the components without all those params. You can only add those when you really need it
Do we need that much of complexity for starting a project? I agree big project needs it for specific use-case.
Great, But now I'm gonna stick with svelte.
You just answered your own question. When you start a big project - you need all those tools so you can easily scale it. If you start working on your personal blog - you choose Svelte, Astro or similar
Agree that the community has become fragmented and that will get worse. Because most apps built with React do not need good performance, a large crowd of people have become stuck on a path that leads nowhere. This has led to the development of the React compiler in React 19. This will further facilitate this split in the community. Other frameworks like Svelte have embraced zero-performance-concern from the start. That might seem cool, but ultimately leads to terrible developers who no longer realize that they're writing JavaScript code with terrible performance, because the compiler will fix it for them.
SolidJS is cool though, I might switch to that once the React compiler blows up in everyone's face.
That's exactly what assembly and perforated cards programmers thought when what we today call "low level programming languages" came out. Look where we are now.
The purpose of new technologies should be to build better stuff in less time. If Svelte compiler will optimize stuff for me, I don't see what's wrong with that. Programming in 2025 is not showing off about who writes the best or fastest algorithm. You have leetcode for that.
Just because things change, doesn't mean you should ignore everything that happened in the past.
Solely relying on the compiler to optimize your code, that's full of business logic and completely losing the skill to spot possible performance issues that could be caused by your code, is not a good idea imho.
As it happens with compiled languages, it then becomes a compiler issue.
Being able to write complex logic relying on a compiler optimizing stuff for you is not a bad thing, it's something we should wish for. This is the value proposition of high-level languages. Knowing what happens under the hood is valuable, but focusing on high-level stuff without having to track every single variable it's empowering.
Only a few applications actually benefit from microsecond-level optimizations. But many of them would benefit from reduced development time!
Knowing that there is a difference between a reference and a value in the javascript language is essential. The React compiler is not going to fix that, it just abstracts the React part into a blackbox, so you forget about those values you keep recreating on every render. The same goes for Svelte and other web frameworks that do magic using a compiler. You are no longer writing Javascript, you are writing React or Svelte.
Your development time argument is nonsense. Adding a useMemo or useCallback takes what? 2 seconds? No React application was delayed because of that. The problem was that people were advocating AGAINST using those hooks, which has spawned millions of terribly performing React applications.
And what's exactly wrong with writing Svelte or React? There are engineers out there working to make the experience with Svelte better because of their work on the compiler. I can benefit from their work and effort, knowing that the code the compiler spits out is most probably better than any code I could ever produce.
That's not true that you need to know that difference, trust me. Lots of application have been written by people knowing nothing of the underlying, and some of them work just flawlessly. It's an added value, but it's not a must have in a lot of cases.
It's just nonsense that you present an example against Svelte using React's useMemo and useCallback. It could take you two seconds to write them down, but for anyone else working on your code it adds up on the developer time to figure out why they are there and fix any bug related to improper usage.
And note, I'm not stating that Svelte is better. But call out a framework because it compiles your code it's a nearly perfect parallel with calling out high level languages because you have no complete control on program and memory flow. Again, not every application needs to save a few milliseconds, especially if that costs you hundreds of thousands in developers time.
Very well articulated ... React is okay, and I use it when I "have to" or when it makes sense - but it's not my favorite, for the same reasons as you've explained so well ...
I've always been a Vue fan, but I'm sure Svelte and Solid are great as well !
Stay a minute, but what about Angular??
@holasoymalva ! Great article—really enjoyed reading your perspective. I can relate to the feeling of “ecosystem fatigue” and the desire for simpler, more modern options. I’m personally a fan of Angular for large-scale, enterprise settings, because it provides an all-in-one solution (routing, forms, DI, etc.) and a solid structure for teams. That said, there’s no “one size fits all” in web development.
Every framework—React, Angular, Vue, Svelte, Solid, Qwik—has unique strengths and trade-offs and i think that good engineers don’t limit themselves to a single tool; they learn to pick the best fit for each project and use it effectively. Whether you prefer React for its community, Svelte for its simplicity, or Angular for its opinionated approach, what really matters is solving the problem well and maintaining a clean, efficient codebase.
So, while React may no longer be your personal favorite, it’s still a great solution in many cases. In the end, the smart move is knowing the pros, cons, and use cases of each option—and having the curiosity to explore new ones. After all, good engineering is about choosing (and using) the right tool for the job.
You need Angular.
This is based on the problems you encountered.
SolidJS svelte could be another alternative but even for small projects Angular gets you situated.
React otoh ecosystem is fragile.
That's why I still love the old and good Angular. Consistency and standards and patterns.
Your "good" Angular is one of the worst performers of 2024.
I don't mind. It just works, it's not just an hype. At least when I need an enterprise application Angular is a good choice and it has been for the last decade. Convince me that I'm wrong.
I feel bad for the people that depend on your judgement, like the users of the applications you make. Or maybe you don't call the shots? That would be ideal for their sake.
Hi José, thanks for sharing your concerns. Angular’s solid architecture, TypeScript integration, and official tooling make it a reliable choice for large-scale enterprise apps. While some benchmarks label it slower, in real-world scenarios it’s been robust, especially with ongoing improvements (like Ivy) and Google’s long-term support.
I’d love to know more about the specific performance issues you’ve seen. Are they still common on today’s powerful (2025) hardware? Honestly, I can’t recall major performance troubles in a properly built front-end since I started using frameworks in 2013—even when I worked with React, Vue, or Svelte. Could you give me an example of something that performs poorly or uses excessive memory? Most issues I’ve witnessed were due to questionable coding practices rather than the framework itself, and a few tips usually solved them.
Sure. This is a website that benchmark signal runtimes: github.com/transitive-bullshit/ts-...
Angular signals are at least 7 times slower than the leader.
Then we have Krausest benchmarking: krausest.github.io/js-framework-be...
Angular can brag about being significantly better than React, but its overall position is not great for such "mature and stable" framework.
reactjs not a framework but library
It's 2025 and we still see this comment 🤷♂️
Maybe because people continue to miss the lesson?
React started as a library but it has evolved. It's the most extensible framework in use.
reactjs is a library that can be combined with other libraries. i. e: Angular is a framework.
since "no one" knows how to set it up as such anymore (see reacts own getting started guides and all the react bootstrapping tools) this is splitting hairs at this point. For all intents and purposes react has become a framework because nearly no one uses the actual library on its own - hence the article.
How about angular now?
I use Formik and Yup schema for form validation
It's simple and easy to use
In the UK can't find a single solidJS job, even though I think it's a great framework. Svelte has a bit more up-take, but still not enough jobs..
I've deffo seen some in the Cambridge area.
This entire set of comments alone is enough to keep me away from JS frameworks.
You guys seriously have way too many words for the exact same things.
Do we really need a dozen ways to say "render", "api call", "include" ?
Meh, don't get me wrong, JS is absolutely the best way to do a nice interactive frontend.
I'm no "we should just use HTML" guy. I get it, been coding a long time to know better, been coding frontend AND backend and doing SEO stuff and DNS stuff and Email stuff, and so on.
JS interfaces are great. The frameworks are bloated pieces of crap because we let hardcore backend engineers [remember, facebook and google started these things] dictate how the frontend should work, that's why you guys need compilers and linters and a billion things installed to even run a basic page when any frontend dev knows you could just write JS and some flat html and css to accomplish the same [with a few dynamic endpoints]
Anywho, my 2 cents.
I couldn’t agree more! Most of the front end applications out there would do just fine with vanilla js and flat html & css, but they choose to use frameworks just for the sake of it.
So, you say all these data handling and packages that makes developers life easier are useless? Example: framer motion. How much time will it take a developer to build that exact same app in html, css , js, rather than using any framework?
No, I didn't say anything was useless.
Frameworks are bloated pieces of crap that duplicate things we can do with vanilla js in a dozen ways we never needed them to. And we NEVER needed to do builds and compiling of JS code. It's only that way because, again, these things were created by backender/hardcore programmers who didn't understand frontend dev.
Also, you should understand the difference between libraries and frameworks.
Framer Motion is an animation library for React. The same guy who wrote that also wrote Motion One which works with vanilla JavaScript.
You can ask him how long it took.
Point is, anyone can recreate any library. Most of those animation libs are huge when you mainly will use, what, like 5 animations across your projects?
Once you learn how to write them in plain JS/CSS, there's no reason to add the entire library to do the job, so you reduce every page request by like 50kb [which on a small site is nothing, but on a heavy traffic site can mean gigabytes of transfer]
Probably someday a framework or library will come changing the current style of writing code and react will be declared old. But currently, the framwork is very popular!
Great write-up! I’ve been exploring Vue and Angular recently, and I agree with your points about React’s ecosystem fatigue. These alternatives feel more structured and less overwhelming to get started with. Do you think frameworks like Svelte or SolidJS will outpace React in enterprise-level adoption, or are they still better for smaller projects?
"Still better for smaller projects" is an unfounded myth. I use Svelte for a big project. Angular is objectively a bad choice because it shares many of React's downsides. Your best bets, IMHO, are Vue, Svelte and SolidJS.
I'm curious. Do you mind sharing how Angular has many of React downsides?
Angular does not use VDOM, does not depend on Hooks to inform re-rendering and reconcilliation like React.
In fact Angular components are only rendered once and subsequently updated by either Zonejs or pure signals (if you don't use Zonejs) which is much more performant. In fact, modern Angular app is more similar to Svelte/Solid because all of them use signals, as compared to React.
Angular has built-in dependency injection from the start while in React it was an afterthought with useContext and Provider.
Angular has built-in forms, routers, animations, form validator, httpClient, interceptors, etc. React has none and depends on a bunch of unregulated 3rd party dependencies trying to break your package-lock file.
I'm not an Angular developer. I have only glanced at it. Angular performs better than react, but it is nothing too impressive in the overall arena. Angular is, undoubtedly, more complex than React, and that's saying a lot because React is already complex.
Then signals: Angular signals are at least 7 times slower than Svelte signals.
If you are tired with react then I suggest you try out Cradova, a new kind of steroids
github.com/Uiedbook/cradova
Note: created by me still maintained after 4 years of development.
Built many apps and sites on it.
Why the hell is Vue not in this conversation as an alternative. It’s bizarre
It’s such an obvious choice that most people are just blind to it. None of the issues mentioned in this article, nor the comments is present with Vue. Given the choice I would pick Vue any day, any time, it’s not even close. I have tons of professional experience with React and Angular and I’ve done some explorations with Svelte, Solid and HTMLX. Neither of these is even comparable to Vue in terms of DevEx. Just look at the most popular/successful tools in the past 2 years: Vite, Vitest, VuePress… All of these come from the same ecosystem. People are just blind to the obvious. Can’t think of other answer to your question…
Same same. There’s a reason that Vue came built into laravel for so long. Those guys are smart.
The alternatives also have drawbacks, sometimes major ones, and tons of quirks. You just have to use them for a few years to find them. In the meantime React will continue to evolve and simplify while having the largest ecosystem. The grass isn't always greener on the other side.
Really interesting ! I’ve felt the same about React lately—it’s just gotten so complex and tiring to work with. I’m curious about Svelte and SolidJS now; they sound like a much-needed change of pace. Thanks for sharing your experience
I've been a fanatic React and then next.js developer since 2018, but as the author, I went away from the framework about 2 years ago and devoted myself to Svelte only. I even contributed some PRs for Svelte5 while it was in early development. I don't regret my choice, and I don't want to go back to React.
I like Svelte because it just adds some concepts to standard HTML and CSS, so the learning curve is really low.
Also the compiler is pretty neat and produces great, fast and small code.
I had a look at Solid and Qwik, but I found Svelte to be much more close to my idea of reactive framework.
Your post really resonated, and I genuinely respect how measured it is — you're clear it isn't "React is dead" and you frame it as a personal fit rather than an objective verdict. That honesty is exactly what makes a counterpoint worth offering. Worth considering: the "ecosystem fatigue" you've outgrown is, for a lot of teams, the very reason to stay. The "choose your own adventure" flexibility is what lets React adapt across hugely different projects — from a startup prototype to a large enterprise stack — where a more opinionated framework would force compromises. Fragmentation that feels like a maze to some people is adaptability to others.
On Svelte and Solid feeling genuinely "simpler and better": a lot of that simplicity comes from being smaller, younger ecosystems — fewer edge cases to hit, and fewer years of production hardening. React's complexity isn't pure cruft; it has had to solve the hard problems at scale, and that concentrated cost is a big part of why the demand and the job market stay saturated.
So yeah, React's weight is real, and I fully understand the pull toward something simpler. I'd only gently push back on the framing that "simpler" automatically means "better" outside of any context. Different problems deserve different tools — and you being genuinely excited about Svelte and Solid is a good sign for the ecosystem either way. Good luck with the switch, and thanks for a conversation worth having.
This is exactly how I feel recently. I missed the time when building application in React is faster, easier and more enjoyable than 500 lines of jQuery. But now, it become redundant itself, I can’t even count how many days have I ask my self in frustrated: “why do I have to all of this just to toggle this select box?”, “why changing just one character in the input takes so much time to handle correctly?”. To be honest, I want to switch to something else, but that not what the current market want, they demands stable developers who do what every other people do, and anyone can maintain it. So I guess that I will still stuck here for a while.
I myself have learned to dislike React for many reasons (and still often use class components as a result), but the reasons given here are honestly moronic. Your #1 complaint is it has too many convenience libraries?
The rest of us have this secret formula called DON'T INSTALL WHAT YOU DON'T WANT. You do realise don't need a CSS library for React, right? You can use good old CSS files or declare styles variables (yes, without a library). You know you don't need a bundler, right? Stop using 30MB+ libraries like Material and your app size drops to below 100kb WITHOUT bundlers, and without chunking. You don't need React Router, I have both made my own solutions and used React Router; which path I choose depends on my use-case. You don't need.... fuck this, I give up.
Yes, totally, abandon a library because it has many options, not because it deviates from its own standards, ignores its dev community, completely misses the plot on what it's supposed to be, and outright betrays its own use-cases. No, let's leave it because it has plenty of support. This is the last ape-grade IQ dev.to article for me, I'm banning this shit from my news feeds.
This post really hits home! React’s growing complexity and ecosystem fatigue are so real. Svelte and SolidJS sound like a refreshing change—what’s your top advice for someone making the switch? Excited to dive in!
I appreciate your thoughtful post, but I'd respectfully push back on a few points. Ecosystem fatigue is real in any mature framework — React's breadth of libraries is partly a consequence of its massive adoption, and that same adoption means battle-tested solutions for nearly every use case. As for simplicity, hooks took time to internalize, but once the mental model clicks, they're arguably more declarative than class components ever were. And while the job market is competitive, "saturated" also means abundant opportunities and a vast pool of resources, mentors, and existing codebases to learn from. Svelte and Solid are genuinely exciting, and I think exploring them is healthy — but switching frameworks is a cost-benefit decision, not a moral one. For teams with existing React codebases and hiring pipelines, the migration cost and ecosystem risk often outweigh the ergonomic gains. Thanks for sparking this discussion!
You nailed it 100%. I really don't understand why people use React anymore, if they have a choice. I think it might just be the vicious popularity feedback loop, that doesn't allow them to look around at (so many) better alternatives. I rarely see a post that I agree with 100% front to back, but this is one. SolidJS is my favorite, although SolidStart was a bit rough for me (when I tried it quite some time ago). I loved Svelte as well, but one of my first loves was Vue and it has reached the point where it's been through some painful changes but is better now on the other side. And very popular so you're still going with the mainstream with it. I have projects in Solid, Svelte, Astro and now back to Vue, all of which are a breath of fresh air after the pain of React. I called Solid "React without the weird quirks and pains".
For static site generation, e.g. for websites and blogs, also take a look at Nue.js, which is a rethink of the whole ecosystem. See also Nue 1.0 (RC) — Can it outshine Next.js? for a comparison.
I respectfully disagree with some of your points. React's ecosystem fragmentation is real, but it also gives developers the flexibility that many appreciate. While Svelte and Solid are great, they lack the maturity and battle-tested ecosystem that React has built over years. Every framework has its trade-offs, and ultimately it's about finding the right fit for your specific project needs.
I'm job hunting, and it does seem like the ubiquity of React.js is a curse as much as a blessing. Lots of jobs I'm qualified for...but so are thousands of other applicants.
I wish I could take a course in Svelte and look for Svelte jobs - but a course won't cut it when employers are looking for on-the-job experience.
Thanks for the thoughtful write-up, Leon. I respect the personal journey you've shared, and I think there's a lot of value in exploring new tools. That said, I'd like to offer a friendly counter-perspective on a few of your points.
On ecosystem fatigue: I'd argue the "choose your own adventure" nature of React's ecosystem is actually a strength, not a weakness. It means you're never locked into one way of doing things. Need a simple app?
useState+ Context gets you surprisingly far. Need something complex? You have battle-tested options. The key is knowing when not to install a library — and that's a skill, not a React problem.On React not being simple anymore: Hooks did add complexity, but they also solved real problems (logic reuse, colocation of concerns). And Server Components, while new, are optional — no one is forcing you to use them. React's core mental model (UI = f(state)) remains as simple as it was in 2013. What's changed is the ambition of what we build.
On the market being overcrowded: This is a fair observation, but it cuts both ways. The sheer volume of React jobs means there's always demand — for juniors breaking in and for seniors who can untangle legacy codebases. The "smaller pond" argument for Svelte/Solid makes sense for early adopters, but it's also a bet on those frameworks' staying power. React's 10+ years of stability and Meta's backing aren't nothing.
On alternatives being "just better": I'm genuinely excited about Svelte, Solid, and Qwik too. But "better" is contextual. Svelte's compiler magic is elegant for small-to-medium projects, but the React ecosystem has mature solutions for things like accessibility (React Aria), complex forms (React Hook Form), i18n, and testing that the newer frameworks are still catching up on. Each has trade-offs — there's no universal "better."
On community fragmentation: I actually see the diversity of approaches as healthy. The React community isn't fragmented — it's a marketplace of ideas. The Server Components vs. SPAs debate, the rise of TanStack Router, the React Compiler — these are signs of evolution, not decay. And with the React team's renewed focus on developer experience (React Compiler, React Server Components, improved docs), the community is actually converging more than it has in years.
In the end, I think we agree on the most important thing: use the tool that makes you productive and happy. React isn't for everyone, and that's perfectly fine. But for many of us, it's still the most pragmatic choice for building real-world applications at scale — and it's getting better every year. Happy coding, wherever your journey takes you.
Great article, Leon — I really appreciate the thoughtful, non-rant tone. It's refreshing to read a "leaving React" post that doesn't declare the framework dead. That said, I'd like to offer a different perspective on a few points.
On ecosystem fatigue: The "choose your own adventure" nature of React's ecosystem is, in my view, a feature, not a bug. It means React itself stays unopinionated and lightweight, while the community innovates around it. The trick isn't to install everything — it's knowing what you don't need. A simple app can go surprisingly far with just
useStateand Context. For complex apps, having battle-tested options like React Hook Form or TanStack Query is a luxury, not a burden. The alternative — a framework that ships everything — often means you're stuck with someone else's decisions even when they don't fit your use case.On React's complexity: Hooks did add a learning curve, but they solved real problems: logic reuse and colocation of concerns. And Server Components? They're entirely optional — no one is forcing you to use them. React's core mental model (UI = f(state)) remains as simple as it was in 2013. What's grown is the ambition of what we build. The React team has also been shipping genuinely thoughtful improvements: the React Compiler, improved docs, and a renewed focus on developer experience.
On market saturation: This is a double-edged sword. Yes, the React job market is crowded — but it's also massive. That means more opportunities, more career paths, and more stability. Betting on a smaller framework like Svelte or Solid is a bet on their staying power. React's 10+ years of stability and Meta's backing aren't nothing — they translate to real-world job security and enterprise trust.
On alternatives being "just better": I'm genuinely excited about Svelte, Solid, and Qwik too. But "better" is always contextual. Svelte's compiler magic is elegant, but the React ecosystem has mature solutions for accessibility (React Aria), complex forms, internationalization, and testing that newer frameworks are still building out. Every framework makes trade-offs — there's no universal "better," only "better for this project."
On community fragmentation: I'd argue the React community isn't fragmented — it's a marketplace of ideas. The Server Components vs. SPAs debate, the rise of TanStack Router, the React Compiler — these are signs of a healthy, evolving ecosystem, not decay. And with the React team's renewed focus, the community is actually converging more than it has in years.
In the end, I think we agree on what matters most: use the tool that makes you productive and happy. If Svelte and Solid do that for you, that's genuinely great. But I'd gently push back on the idea that React is "designed for 2013." It's a framework that has evolved remarkably well — and for many of us building real-world applications at scale, it remains the most pragmatic choice. Happy coding, wherever your journey takes you!
Great write-up, and I respect the honesty behind it — but I'd gently push back on a couple of points.
The "ecosystem fatigue" argument is exactly what made React a safe choice for years: the same fragmentation you call a maze is also the reason there's a battle-tested library for just about any edge case. The trade-off of having to pick tools is the price of not being forced into a single vendor's way of doing everything. Svelte and Solid feel simpler largely because they've had far less time — and far fewer production constraints — to accumulate those hard-won ecosystem pieces yet. The comment thread here (forms, DI, migration pain) is a perfect example: those gaps get solved in Svelte/Solid too, just usually with less mature 3rd-party options.
Performance and DX are real, and Solid genuinely deserves praise. But for most enterprise teams, the deciding factor was never going to be bundle-size microbenchmarks — it's the size of the hiring pool, the years of accumulated knowledge, and the certainty that the tooling will still be around in 5 years. On all three, React's maturity is an asset, not dead weight.
If the framework was dragging you down personally, moving on is completely fair. But I'd caution readers against reading one dev's project fit as a universal verdict on a framework the whole industry still bets on. Curious to hear how Svelte serves you when you hit a genuinely complex form or a big migration!
Why I'm still sticking with React (and a friendly pushback)
I really appreciate the honest, reflective tone here—it's clear you put genuine thought into this, and unlike most "React is dead" posts, you made the effort to acknowledge React is still a good tool. So my pushback comes from a place of respect.
A few points I'd push back on:
"Ecosystem fatigue" cuts both ways. Yes, React lets you "choose your own adventure," but that's exactly why it keeps winning. Svelte and Solid have smaller ecosystems precisely because they're younger—not necessarily better. When you say React means "cobbling together a dozen libraries," the counterweight is that Svelte's "batteries included" philosophy means you're locked into Svelte's way of doing things, for better or worse.
The "React isn't simple anymore" argument is partly about the whole web stack, not React. Server components, useEffect deps, rendering lifecycles—most of that complexity is inherent to modern front-end engineering, not invented by React. Svelte 5's runes and signals-based reactivity are arguably just as conceptually demanding once your app grows past the tutorial stage.
"The alternatives are better" is largely a honeymoon-period observation. Every framework feels like a "breath of fresh air" when your projects fit its sweet spot. Try building a large, legacy-heavy enterprise app or shipping an incremental migration of a React 16 codebase with Svelte and the shine wears off fast.
"Market overcrowded" is actually a sign of stability. A saturated job market means React skills are portable, plentiful, and unlikely to vanish. Betting your career on a "smaller pond" can pay off, but it also carries real risk if adoption stalls.
I'm not saying React is objectively better. I'm saying the grass is always greener on the other side—and React's complexity is the price of its long-term dominance. Curious what happens when Svelte/Solid hit the same scale problems React's had to solve over a decade.
Good luck on the new stack though—genuinely hope it reignites your passion. 🚀
Nice write-up — I found a lot to agree with, especially around the practical "choose your own adventure" fatigue. That's a real cost, and I respect that you framed it as a personal fit decision rather than another "React is dead" hot take, which it clearly isn't.
That said, I'd push back gently on two points. First, ecosystem fragmentation cuts both ways: the same choice-meal that feels like a maze to one developer is flexibility that lets a team tailor a stack to its actual constraints (bundle size, team seniority, legacy integration). A lot of that "spend time wiring libraries together" is often really the cost of using a library-level renderer instead of an opinionated framework — so it's partly a category expectation more than a regression in React itself.
Second, the comparison to Svelte/Solid isn't entirely apples-to-apples once you weight maturity and hiring. Their simplicity and DX are genuinely refreshing (I like them too), but they trade that for younger tooling, smaller ecosystems, and, realistically, a thinner talent pool for enterprise work. For greenfield and small teams they're great; for "framework designed for 2025," I'd argue the alternatives are designed for a different kind of problem, not strictly a newer one.
Either way, good luck with Svelte and Solid — the best tools are the ones you enjoy using, and it's a strong signal that you thought about it on merits rather than vibes.
Fair points, and I'm glad you didn't frame this as "React is dead" — because it isn't. A lot of what you describe (ecosystem fatigue, the steep learning curve around hooks and server components) applies to any mature framework after a few major versions, not just React.
Where I'd gently push back: for a huge portion of real-world teams, the "overcrowded" React market is precisely its greatest asset. It means battle-tested libraries, an enormous talent pool, and answers to nearly every problem already being a search away. Switching to a smaller, less crowded pool is a valid personal preference — but for long-term projects or enterprise teams, predictability and hiring are often more valuable than simplicity.
The alternative frameworks you mention (Svelte, Solid, Qwik) are genuinely exciting, and it's great that you found tools that reignite your passion. I just think — and you almost said this yourself — "better" really means "better for me and my context." Framework choice should serve the project and the team, not the other way around.
Best of luck with Svelte and SolidJS. 👏
A thoughtful counterpoint from a long-time React dev
Great write-up, and I respect the honesty - migrating off a stack you've invested years in takes real self-reflection.
That said, I'd gently push back on a few points:
'Ecosystem fatigue' is a feature, not a bug. The breadth of choices exists because React is a library, not a framework—you assemble exactly what your app needs and no more.
'The market is overcrowded' cuts both ways. It also means demand is huge—more React jobs than Svelte+Solid+Qwik combined, which is a liquidity advantage for most developers.
Newer frameworks are simpler and faster, but React's maturity—RSC with a well-chosen framework—still wins for teams optimizing for hiring, stability, and proven patterns.
'Not for you' is a totally valid and right call for you. But for many teams, 'boring' is exactly what a business needs in 2025.
Curious which point weighed heaviest in your decision?
Thanks for sharing the thoughtful points about ecosystem fragmentation and the crowded market — those are fair and well-articulated. I'd push back on the framing a little, though. React's "choose your own adventure" ecosystem is often described as fatigue, but in most real projects it's a strength: a huge, stable library and a talent pool that lets teams reach for battle-tested solutions and ship faster. From what I've seen, if you hop to Svelte or Solid, you just trade one set of migration costs and version churn for another — both are genuinely lovely and I've enjoyed them, but they come with a smaller ecosystem and fewer mature libraries to lean on. So the real lesson might not be "find a simpler framework" but "pick the stack that fits your team and constraints, and double down on fundamentals." Either way, I respect that you're exploring what reignites your enthusiasm. Nice read.
I was thinking similarly a year ago
orizens.com/blog/why-i-chose-astro...
I think astro is innovative and still offers some familiarity to what I've used to work with while let you try new and fresh frameworks.
However, i see React is evolving abd interesting to see how the community will embrace it.
I hear ya — I too have React burnout. I guess whether to double down on React or leave it depends on where you are as a dev. For novice and junior devs, I expect they'll need solid React knowledge in order to get work. Myself, I like the look of Svelte and will focus on that a bit this year. I feel that spending too much time in React land is actually making me a worse developer. Time to go make a todo app with Svelte guess!
Great article, Leon — I really appreciate the thoughtful tone and the fact that you're not declaring 'React is dead.' That said, I'd like to offer a respectful counterpoint on a few of your arguments.
Ecosystem fatigue → a feature, not a bug. React's 'choose your own adventure' nature is precisely what makes it durable. Monolithic frameworks lock you into one way of doing things; React's unopinionated core lets you pick the right tool for each job. Yes, it requires more decision-making upfront, but that flexibility is why React has survived while more opinionated frameworks have come and gone.
Complexity vs. capability. Hooks and Server Components aren't arbitrary complexity — they solve real problems. Hooks replaced class lifecycle methods and mixins, which were far more confusing. Server Components address the fundamental tension between interactivity and performance. These aren't features bolted on for the sake of it; they're responses to genuine needs at scale.
Market saturation → a signal of value. React's ubiquity isn't just a curse — it means a massive talent pool, mature tooling, battle-tested patterns, and corporate backing from Meta. For enterprises, that's not overhead; it's insurance. Niche frameworks may offer less competition for jobs, but they also carry more career risk.
'The alternatives are better' → better for what? Svelte's simplicity is real, but it's also a younger ecosystem with fewer production-proven patterns at scale. SolidJS is fast, but speed isn't everything — developer experience, ecosystem maturity, and hiring pipeline matter enormously in real-world projects.
All that said, I completely agree with your closing sentiment: the right tool depends on the project. I'm glad you found your fit in Svelte and SolidJS. But I'd argue React's complexity is the price of its ambition — and for many of us, it's still worth paying.
Great article, Leon — really enjoyed reading your perspective and I can tell this comes from genuine experience, not just hot takes. That said, I'd like to offer a respectful counterpoint on a few of your arguments, because I think the picture is more nuanced than "React is old and tired."
On ecosystem fatigue: I'd argue this is a feature, not a bug. The "choose your own adventure" nature means you're not locked into one way of doing things. Need a lightweight state solution? Zustand. Need something more robust? Redux Toolkit. The ecosystem gives you options, and the cream rises to the top — React Router, React Hook Form, and TanStack Query have become de facto standards that most projects converge on. It's not the wild west you describe.
On complexity: Hooks did add a learning curve, but they also made logic reuse dramatically easier compared to class components and HOCs. And on Server Components — they're optional. You can build perfectly fine React apps without touching RSC. The React team has been clear: React is a library, not a framework. If you want a batteries-included experience, Next.js exists. But you're not forced into it.
On market saturation: This is true, but it's also true that React jobs pay well and are abundant. The "smaller pond" argument for Svelte/Solid is valid for career differentiation, but it also means fewer opportunities, smaller communities, and less enterprise backing. The risk/reward calculus isn't as clear-cut as you suggest.
On alternatives being better: Svelte and Solid are genuinely impressive, and I'm glad they exist — competition makes everyone better. But they each have their own trade-offs. Svelte's compiler magic is elegant until you hit edge cases where you need fine-grained control. Solid's ecosystem is tiny compared to React's. These aren't dealbreakers, but they're real considerations for production apps that need to ship and scale.
On community fragmentation: I'd flip this — React's diversity of thought is a strength. You can find your tribe within the ecosystem. And the core React team has been remarkably consistent in their vision (from class components to hooks to RSC, each step was a logical evolution). The "fragmentation" you describe is really just a mature ecosystem where different teams have different needs.
Ultimately, I think we agree on the most important point: the right tool depends on the project and the team. React isn't the only answer, and it's healthy to explore alternatives. But I'd caution against framing React as "a weight I don't want to carry" — for millions of developers and thousands of companies shipping production code every day, it's still the most reliable, well-supported, and battle-tested option out there. That's not fatigue — that's trust.
Happy coding, wherever your stack journey takes you!
It's true that I'm an old geezer when it comes to the web (since 1998) but I still find nothing wrong with basic vanilla stuff. I just completed a new site last month and all I used was HTML, JS, CSS and a little bit of PHP and HTMX for good measure, no DB's in my case either, even if the site is static-ish..
Site is easy to maintain, not overbloated and super fast.
No pre-processors or build tools, nothing, very simple. Easy to update and backup.
All these frameworks are making me uneasy, especially because they try to re-invent each other every few years, all in the name of trying to ship quality code faster...nah, I'll stick to my vanilla ice-cream. Nothing to re-invent, always the same stuff to get used to, which does make me faster and faster each time and gives me some time to have a life in between..
Just my 2 cents mind you, works for me.
Same thought, bro. Now I'm slowly shifting to SolidJS, React is just for office-related work.
How has your experience been with SolidJS? I am thinking of using it for a side project.
I habe been on jamstack for years, refused to pickup a frmaework due to laziness to learn somethinh new because i was very satisfied with the expressJs and reusable component capability of Ejs template engine
Angular is the way (In my opinion)
Just use Data Star its so much simpler once you understand how it works.
Liveview
There is no alternatives only vanilla js.
How do I know all this frameworks available in Market, how can I keep myself up to date.
You should check out Vue too
You should give Nuxt a try, they place huge emphasis on developer experience. its really good
Interesting to see a different perspective.
Everytime I saw this title, you will be back to react soon.
I preffer angular million of time
I just use good old fashion JavaScript, hadn't problem with it yet.
Dammnn !! Haven't read this good article and discussions for a long time. Super cool article with cool people chatting in the comments, feels so alive to me. Learned a lot . Thanks
Thank you. It's time to ditch React in favor of productive frameworks!
I've been saying this now for a few years. In fact, I would get away from any Javascript framework bigger than Alpine JS or HTMX.
You have to try Riot.js guys. Nothing could be more clean and simple than that