second this, plus its mature ecosystem, which is very valuable for the long term.

though, the SSR madness movement including React concerns me, everyone tries to mix CSR and SSR into one now, which makes things way more complex than it needs.

I could not agree more. There is a huge push to make both side of the rendering “the same”. Next.js is pushing it really hard for their edge level rehydration.

I get it, it gives you flexibility to hydrate the view as close to the user, as late as possible. That sounds cool, but I wonder how many folks really use it and how much you pay for not clearly defining where and when each bit is happening.

As someone who tries to limit their client-side JS usage through uBlock/uMatrix, websites that aren't just blank <div id="root"></div> with JS disabled would be nice to see, which is why I like React Server Components. Of course, if it's a useful enough web app, I'll enable JS, but if someone's writing a blog, ecommerce site, or really any site that may not require a full blown SPA. Sending minimal unneeded JS to the client is best, as it saves bandwidth and battery, as well as feeling faster due to loading faster, in my opinion.

You can also achieve this with Astro, which will render your React islands statically and also enable client-side JS for interactivity / progressive enhancement when the client has JS enabled

True, however it's wrapped up in a nice DX in NextJS. In Astro, if I have multiple components that need React interactivity, are they all separate React apps basically? Or are they the same but with different roots? In NextJS, they're the same and Next can intelligently figure out which to render server side and which to render client side.

If I understand correctly, the React runtime is shared between islands (and you can share state between them if necessary), but they're also pre-rendered for their initial state at build-time.

So you can't do as much in Astro as you can in Next.js, but it will definitely scratch the itch of compile-time rendering.

I agree with you. It seems wasteful to spending a whole "wait around period" for that <div id="root"/> to eventually load once the js gets around to it.

I also agree that server components make a lot of sense to solve this problem. It's the obvious optimization (and in some ways, a good re-learning from past wins with PHP, Ruby, etc).

I also still feel we have a long way to go before it becomes elegant and obvious how all this is working. It hasn't become standard in the way that everyone easily groks the concept of how it all works and expects it everywhere on every web stack.

Still waiting to see if we go down another rabbit hole of complexity, or see more cautious and careful improvements towards an easier, more maintainable environment.

The "ecosystem" is taking vanilla js libraries that work without modification in other frameworks and making them work with react via a wrapper. The react ecosystem is nothing.

React Three Fiber is a good “wrapper” library that proves the ecosystem is far from “nothing”

https://docs.pmnd.rs/react-three-fiber/getting-started/examp...

I know what react three fiber is and I find the idea of using xml for 3d rendering to be terrible.

I disagree—I regularly find (and use) libraries that are built specifically for React and don't have a vanilla JS analog. As someone who uses Svelte on personal projects, I actually find this really frustrating and wish most of these libraries were just wrappers over some core functionality built without React.

I have a similar feeling. I keep up to date on changes to these other frameworks but in my work we've never run into React performance issues that couldn't be fixed by approaching things with good principals. Signals are brought up in convo every now and then as an approach to fix an issue, but stepping back we always seem to find a better solution but just re-writing bad React code. I'm sure if you're on a certain scale of users or extremely custom UI you could run into circumstances where signals would help you, but for our system that serves hundreds of thousands a day, we don't need them yet.

I've worked on react codebases, and non-react codebases. Maybe it's a coincidence, but I find the react ones in general to be harder to debug. And not great for my sanity either.

My experience is it tends to depend on the folks who made the application. Regardless of what framework you chose, they can't save you from yourself in a lot of cases.