I have not looked at how this framework does it, but I have built a nodejs server that does similar things myself. Some advantages:

- The server can render the full page in html for the client, which means the website is viewable even without js (or before js has loaded, for example on slow network)

- The server can preload all data the client needs. The webapp might need to fetch data from 3 API endpoints. Having a server do this and pass the results to the client on load is much more efficient. If the client (browser) loads it, the following happens: html loaded -> js loaded -> start calling APIs. If the server does it, the client instantly has access to this data.

Rendering all the html can be a bit heavy on a weak server though, but you get the advantage that you quickly notice bottlenecks in your rendering. You can also implement some caching on your server to make it faster.

I appreciate your answer, which seems to apply to the general concept of server rendering. But Django can also do all what you mention. My question was: what can React-Server do that Django could not? I hope this clarifies my original interrogation.

The difference is that a "react server" can actually render the dynamic react content. I don't know of a way to do this in django, unless you are able to run javascript code somehow. If you do this, you are kind of making your django app a "react server" though, since it renders all of your react components.

What usually happens in a react app is that the server delivers static content (html, js, css). When everything is loaded, react starts working on the browser and renders / fetches data.

If the server that delivers the html doesn't just deliver a static page, but actually fetches data and renders it first, the browser can instantly display the data and react is smart enough to know that it doesn't even need to do a new render, because the components are already rendered to html.

It's just my opinion, but I think this architecture is only advantageous when you need to build something with a complex user-facing CMS. Think lots of forms and controls with real-time feedback, optimistic updating, drag and drop sorting, etc. Across many pages with many object schemas. If this is the case, you'll save time by setting up a flexible module system with predictable data flow. Users will spend less time waiting for pages to load and edits to save. If this is not what you're building, stick with traditional server-side templates and a little bit of JS on the front end. I certainly wouldn't use this stack on a corporate marketing site, for example.

Shared client/server code.