Why I Decided to Stop Working with React.js in 2025 - DEV Communitydev.to › holasoymalva › why-i-decided-to-stop-working-with-reactjs-in-20...

## 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. … ## 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. … 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 🤣 … 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. … 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? … Ilya Gorenburg • Jan 14 '25 ... 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? … 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. … 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. ... 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 `@NgModules` do the `declaration`, `imports`, `providers` etc. Also the file structure `dir/component.css`, `dir/component.html`, `dir/component.ts`. You can write three things in one when you write in basic `component.html`. … You can check svelte project that I have stared over the period: github.com/theetherGit?tab=stars