Anything beats next and react server components for me. It’s a mess of lock-in and complexity that brings very little. It also changes all the time, the maintenance cost is _crazy_ compared to almost all other mainstream options, the ROI is super low.
Next.js and similar are surprisingly complicated. You pay a hefty price for the optimization of SPA + data on the first request (which is a cool optimization).
I think one of the reasons it's so popular is less about the niche optimization and more about how it seems simpler, especially to beginners, than running an API server that your frontend app connects to.
Such a generic question, with probably hundreds of possible answers, it really depends on the context. From the top of my mind, whatever library/program you wanna use only being available in $Language comes to mind as something you encounter at least once in your career as a programmer.
> From the top of my mind, whatever library/program you wanna use only being available in $Language comes to mind as something you encounter at least once in your career as a programmer.
That wouldn't be a reason to also write your CRUD backend in that language. You would just make it a separate service written in that language.
I rather include a WASM Component that uses $library and pass data within the program, than setting up an entire service doing the same thing, but now with web transport complexity.
As someone who lightly dabbles in React my interpretation of that comment is “what’s not to like? It solves at least some of the problems React itself introduced!”
You never had to do state management before React? Maybe it wasn't called that but I definitely had to manage some state between frontend and backend in webapps.
Also it's hard to tell what problems come from React and what from any SPA. As I keep familiar with React development I'm inclined to say that almost all React problems people are complaining about are SPA problems and modern React is the only framework that even dares to try to solve them and does it increasingly successfully.
I've written a fair few Solid apps. I've never felt the need to reach for 3rd party tools to help manage state. In my experience, solid's built-in signals (& resources) are enough on their own for simple apps. And when I need something more complex, you can build on top of them if you know what you're doing.
If anyone is curious, here's an interactive, editable tutorial teaching how solidjs signals work. If you haven't seen solid before, its similar to react but components don't re-run whenever their state changes:
I agree that Solid signals and resources are robust, but they are still very similar to React's useState and useEffect, and you are basically suggesting to implement your own state management library. Regardless, with React server components, there is no need to manage state on the client at all.
Cant speak for Vue or Solid, but in Angular this has never been a big issue like it is in react. There is state of course but it is not something you have to actively think about all the time. State is kept as properties in classes, directly on your component or (when it needs to be shared) in services that can be injected. Angualar change detection will update the view when needed.
You can argue about the performance of this, but in my experience it is easier on the developer.
When a dynamic web app is needed, the general trend is to build SPAs, which in turn require managing state on the client, which is complex and thus redux et al were invented.