I believe there is a project (not sure if it’s active) called JSX2 that treated this as exact problem as a first class concern. It was pretty fast too. Emulated the React API for the time quite well. This was 4-5 years ago at least

The "Pay what you like" button right under the title when I have not read any thing is really off putting

Is Dan reinventing Astro?

The biggest draw that pulled me to Astro early on was the fact that it uses JSX for a, in my opinion, better server side templating system.

From the final code, this is called for every rendered post:

    const post = await getPost(postId);

But...we should basically never be doing this. This is totally inefficient. Suppose this is making a network call to your Postgres database to get the post data. It will make the network call N number of times. You are right back at the N+1 query problem.

Of course if you're using SQLite on a local disk then you're good. If you have some data loader middleware that batches and combines all these requests then you're good. But if you're just naively making these requests directly...then you're setting up your app for massive performance problems in the near future.

The known solution to the N+1 query problem is to bulk load all the data you need. So you need to render a list of posts, you bulk load all their data with a single query. Now you can just pass the data in directly to the rendering components. They don't load their own data. And the need for RSC is gone.

I'm sure RSC is good for some narrow set of cases where the data loading efficiency problems are already taken care of, but that's definitely not most cases.

some of the presented problems of the "good ol' REST endpoint" approach feel a tiny bit of a strawman, like "you can't add endpoints because /get/posts is taken", but having to cobble together a response from multiple calls (and all it entails, such as loading states) because is a very real and I feel very shared pain. And in my experience, too, GraphQL has been an unsatisfactory solution.

A BFF is indeed a possible solution and yeah if you have a BFF made in JS for your React app the natural conclusion is that you might as well start returning JSX.

But. BUT. "if you have a BFF made in JS" and "if your BFF is for your React app" are huge, huge ifs. Running another layer on the server just to solve this specific problem for your React app might work but it's a huge tradeoff and a non starter (or at least a very hard sale) for many teams; and this tradeoff is not stated, acknowledged, explored in any way in this writing (or in most writing pushing RSCs, in my experience).

And a minor point but worth mentioning nonetheless, writing stuff like "Directly calling REST APIs from the client layer ignores the realities of how user interfaces evolve" sounds like the author thinks people using REST APIs are naive simpletons who are so unskilled they are missing a fundamental point of software development. People directly calling REST APIs are not cavemen, they know about the reality of evolving UI, they just chose a different approach to the problem.

Step by step coming back go JSF.

I knew this post would eventually peddle me nextJS, and it did!

The power is in react context for children to refer to parent state. Rsc completely solved the restful thesis. A rsc returns a spa with streaming data. It also solved the microfrontend architecturally. It is the end game.

Spa developers missed the point totally by reinventing broken abstractions in their frameworks. The mising points is in code over convention. Stop enforcing your own broken convention and let developers use their own abstractions. Things are interpreted at runtime, not compile time. Bundler is for bundling, do not cross its boundary.