React Server Components Explained

Ethan Glover

Dan Abramov has always been a great resource for clear and concise explanations of some of the technical decisions and directions of React. With RSC imminent, his latest tweets have been a great way to get a full understanding of why one would use RSC rather than something like Remix, Turbolinks, Islands, etc. I wanted to put one of his tweet threads into a longer blog form, but you can find the original here.

React Server Components Architecture

In the above image, server components are blue and run only on the server. They are able to securely access a database, the native file system via Node, etc. The green components are client components. They run on both the client and server. But they can not use server-only features. They have to be able to run on re-renders. To put it another way server components send static HTML to the browser along with the JSON needed for client components to hydrate.

In frameworks like Remix and even NextJS 12, everything is green except loaders or getXProps. So for every route, there is only one blue part. And these blue parts are not composable further down the tree.

Compared to Astro, both blue and green parts exist. But they're written in different languages. Astro and React. There is also no support for rerendering the blue parts such as on navigation or mutation after the page loads.

Compared to Rails/Turbolinks, the blue parts are refetchable but written in a another language (templates). They also have to be synchronous (even when reading from a DB), and the state of the green parts are lost on refetch. This is not seamless.