(For some background, I used to code SPAs from scratch with vanilla JS and jQuery in the 2000s, then switched to backbone.js then Angular, before picking up React that solved all the design issues of Angular)
You need to use a separate library for CSS with React. Svelte has the best way to deal with CSS built in. Which CSS library do you choose for your React project? There are so many libraries to consider, and so many bugs in each of those libraries.
You need to use a separate state management library with React. Svelte has state management built in. Which state management library do you choose for your React project? There are so many to consider, and so many bugs.
People think they want to use React because of the "ecosystem." But, they don't realize that React coerces you to use an ecosystem, an ecosystem that is full of buggy software and those bugs create impossible permutations of configuration issues and bugs (see Create React App). Bugs are not specific to React at all, all software has bugs. But, React forces you to use an ecosystem, and that's a bad thing. I write a lot of Svelte code with very few external libraries.
React does give you job security fixing all those bugs. I'll give you that. It is a wise career choice.
Svelte 5 is a big change. But, today, I refactored a bit of reactive code (which talks to a server and uses async code) inside a single template into an external shared component. That component has reactive code that can be shared across Svelte UI components. I could do that before with stores, but I had to be careful about how to use the reactivity. This new component isolates the reactivity in the right way and shares it in the right way. And, that share component is testable. It is an incredible experience when you get it.
I mean you can just use CSS. Personally I use css modules. Not very buggy or react specific.
> a separate state management library
Yeah I do use tanstack query to manage server state. Does Svelte include something similar out of the box? Otherwise it’s 1) url/query param for app state 2) tanstack query for server state 3) hooks for reusable state or local component state. Not many library bugs with that approach and tbh I’ve never needed something like redux or zustand.
Then it became “wait just don’t use hooks till we work out the issues.”
Problems galore in react, you should try out new js frameworks. Atleast vue and solid, to see what else is on the table
Though I agree trying other frameworks is a good practice. See what you're missing, or understand your preferred framework better.
If you are building an SPA there is no reason to choose something other than React. Many of these other frameworks focus on apps that aren't full-blown SPAs. Htmx, deno fresh, astro, remix, next.js, these are all designed for users that don't want SPAs.
I think that's great, but often we conflate these use cases which cause mass confusion. Htmx is not great for highly dynamic "desktop class" web apps and the same goes for next.js.
Previously,class components were the primary way to manage state and lifecycle methods.
Lifecycle methods like componentDidMount, componentDidUpdate, and componentWillUnmount were heavily used.
Now, functional components with Hooks (useState, useEffect, etc.) are the best practice. There were several iterations of different practices in between.
Previously, props were passed through multiple layers of components (prop drilling was established practice).
Now Context is used. State management, event handlers, component structure, CSS-in-JS: pretty much everything has changed over time.
No - I used React in the past, but no longer use it. Maintenance is a head-ache. I am utterly certain that within the next 2 years, another "life-changing" React paradigm will come into effect - can even bet on it.