React Server Components are without a doubt one of the biggest changes to React since... well since ever. I remember React introducing Hooks, which was a big change in "how to write" React and it did come with some mental hurdles that needed to be overcome. Making sense of composable hooks and dependency arrays took some time and to this day I see React developers getting confused over the correct usage of useEffect. But this is nothing compared to the change of React's mental modal introduced by RSCs.

This won't be a text helping you understand RSCs on a deeper technical level. If you're looking for this, I can't recommend Dan Abramov's blog overreacted enough. Starting with The Two Reacts Dan did a great job of writing blog post after blog post finding different explanations with different comparisons and examples, to help everyone get a grasp on what RSC is and what it is not.

If I had to pick one key takeaway from all these posts it would be the following: RSC is not (I repeat: not) Server Side Rendering. Instead RSC is an API layer between two systems, typically a browser client and a http server. So where's the difference? With SSR the server pre-renders React code into HTML and sends it to the browser, so the browser can skip the initial heavy lifting. It's a one-way-communication between the server and the browser. All communcation that happens after that has nothing to do with SSR. In fact in some cases the server handling the SSR won't be handling your API calls. With RSC on the other hand we get a server that handles an ongoing communication. Actions from the client will be sent to the server, which will respond to these actions with changed React elements.

This is not new. In fact when I talk to more backend focused developers about this, they keep scratching their heads over my excitement. Isn't that what we've been doing all along with Ruby on Rails, Django, Laravel, Phoenix, [fill in your favorite full stack framework]? Aren't Hotwire (for Rails), LiveView (for Phoenix), [fill in your favorite frontend live update solution from a fulll stack framework] providing exactly what RSC is trying to achieve? Well, the obvious answer to these questions is: Yes, in a way. And so the obvious follow up question popped up: Why would we bother using RSC, if we still have to put another backend solution behind it?

Well now we're getting technical. Since developers are used to having React in the frontend, they are used to having some backend solution backing it. Next.js and other existing full-stack React frameworks didn't change this much. Mostly because they did not provide the runtime and tools to be used as a standalone full-stack framework, but now that React comes with a built-in paradigm to do server client communication, I don't see why there shouldn't be a standalone full-stack framework powered by React. Next.js just started supporting having all of its code run in the Node runtime - absolutely essential to be able to do direct connections to a database (without relying on proprietary 3rd party solutions). With TanStack Start, React Router and Waku we have three other frameworks in the making, that will soon be RSC-first.

So what's my point here? While React Hooks changed the way how to write React, they did in no way change what React is. This is not true for RSC. RSC not only changes how to write React, RSC changes the nature of React. Let's call it by its name: React with RSC is a full-stack library. It will be powering a bunch of full-stack frameworks. This won't mean you won't be able to do your heavy client stuff with React anymore. The one of the two React's will still be there. But if you want to make sense of the future of React, you need to get to know the other React, you need to embrace RSC and you really need to stop putting use client everywhere without knowing what's happening - been there, done that.

My homepage is powered by Waku, a RSC based full stack React framework in development. Blog posts are fetched from leaflet.pub via ATProto. Feel free to browse the code and see RSC in action.