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

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.

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)

The things you've described do not require react.

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.

Ejs.

Ejs is very much string-based.

Svelte already has that and much simpler and more performant than react does.

If they won't do it, they'll fall behind.

With Svelte I can render a reactive statically rendered website. Nothing to my knowledge can do that in the JS framework world.

In my experience, Svelte made me much less productive because I was fighting with magic. I'd get stuck on obscure issues for hours.

I needed to learn something to build an app, and react was complex, so I tried Svelte.

With no experience, both seem like fighting with magic. I get stuck on obscure issues for hours.

I would have thought this whole process would be significantly more straight forward at this point.

This is a good point. Svelte has a lot of 'magic' under the hood but a lot of it does not look like magic which can lead to confusion.

The docs are pretty complete and well structured. There are of course obscure issues, but most of the footguns folks run into for typical use cases (e.g. doing something like using an array method and expecting reactivity) are well documented, and solutions on avoiding them are easy to find.

This means that if you do run into something which is not completely intuitive in Svelte, it's normally because there's not an intuitive way of doing it, which means you do more 'ad-hoc' learning as you try to work out what you need to do to get things working the way you want, and sometimes it's easy to fall into the trap of thinking that something that should work is not working.

React does less to 'hide' its magic and makes you work harder mentally up-front to understand what it's doing in terms of component lifecycle etc. In exchange, because it doesn't look as intuitive, you're a bit less surprised when it doesn't work.

For example, in Svelte, you might create something like:

  <script>
    const colours = ['red', 'white'];
  </script>

  Colours of the British Flag

  <ul>
    {#each colours as colour}
      <li>{colour}</li>
    {/each}
  </ul>
  <button on:click={() => colours.push('blue')}>Add blue!</button> 

If you click the button here, nothing happens, because you only mutated the array, which doesn't trigger reactivity. If you're not aware of this, you might not immediately understand that you've made a mistake.

A similar React component would look something like:

  function () {
    const [colours, setColours] = useState(['red', 'white']);

    return (
      <div>
        Colours of the British Flag

        <ul>
          {colours.map(colour => (<li>{colour}</li>))} 
        </ul>

        <button onClick={() => colours.push('blue')}>Add blue!</button>
      </div>
    )
  };

You'll get an IDE warning that 'setColours' is unused, and anyway, you already wrote the code to destructure the 'setColours' function out of 'useState', so you theoretically should know that you need to use it, the mistake is 'clearer'.

> render a reactive statically rendered website

Regular old react without server components has been able to do this long before Svelte existed with SSR

> render a reactive statically rendered website

Regular old react without server components has been able to do this long before Svelte existed. Next.js has done it since day 1. Server components solve for something else