[mu53]

I think the React team is responding to current trends. SPAs were super trendy. Once people started building them, they recognized that SPAs are much harder to optimize than the code for a single page. Next.js came in, and everyone has slowly been shifting to SSR.

If the react team doesn't react, other frameworks will eclipse them.

While I don't like the implementation details, I can see what they were going for. Encapsulating certain API calls behind the server adds a new layer of security that react didn't have before. It's good it is opt-in

[boringuser2]

I've never seen the use-case.

If you're building trivial brochure pages that need SSR for adsense, you shouldnt be using react at all.

If you're building complex apps, it doesn't really make much sense to put the burden of rendering on your server.

[5Qn8mNbc2FNCiVV]

That's the gap server components fill. With SSR you always had the option to just use React on the server and send HTML back, no JS or hydration needed. But if you then want a single widget on the page you can go back to the old (not saying bad) days where you include some clientside js that attaches event handlers and changes some HTML. Or you mark that one component with "use client" and you're done and can seamlessly to your declarative rendering on the client and use the same components you already have.

The RSC part is mostly the streaming of the JSX result, but this only solves the issue that the market wants to work in a MPA way with the routing benefits of a SPA.

Again, nothing new, Turbolinks existed and replaced sections of your HTML with XHR, but you had to slice it up yourself and manage interactions again if the section you changed required JS. RSC takes away the latter part and you're only required to define the boundaries. That's the reason why RSC has it's place, you're able to mix and match it within the same codebase instead of maintaining one codebase for your marketing pages and one codebase for your application (and one for your docs)

[mu53]

A lot of companies depend on search indexing from google and other platforms. E-Commerce, blogs, and trivial information websites all need their traffic to come from somewhere.

If you were going to dynamically render the page anyways, why not do it in node with the best UI framework out there right now?

The burden isn't that much when you put a caching CDN in front of it.

[boringuser2]

The things you've described do not require react.

[8n4vidtmkvmk]

What's a good template engine that isn't string based? Jsx and Jade are the only 2 I know. I guess you can use jsx without React if you want.

[boringuser2]

Ejs.

[erhaetherth]

Ejs is very much string-based.