I have been using React Server Components for a few months now. The blog runs on Next.js App Router. I have mixed feelings about it.
The mental model shift was brutal. For years, React was a client-side library: everything rendered in the browser, and data fetching was the client's job. Then RSC comes along with components that run on the server and never ship JavaScript to the client. I like the concept, but the learning curve was terrible.
The "use client" boundary is where most of the pain lives. You are writing a component and everything is fine until you need useState or useEffect or any hook that implies interactivity. Now you need to split your component into a server part and a client part, connected by the "use client" directive. This is not hard in theory. In practice, you end up with a file structure that looks like someone dropped a grenade in your components folder. ServerWrapper imports ClientButton which receives data from ServerDataFetcher which is a child of ClientLayout. The dependency graph becomes a game of hopscotch between server and client.
The good parts keep me using it. Purely presentational components ship no JavaScript to the client, so your blog post page sends no JS for them (the framework runtime still loads). For initial data, you async/await in the component, with no useEffect, loading state or race condition. The component runs on the server, fetches the data and sends the rendered HTML. This is how it always should have been for read-heavy pages.
Streaming is the part I value most. With Suspense boundaries, your page can start rendering immediately and fill in slower sections as they resolve. The user sees content quickly even if some data takes 2 seconds to fetch. This is not new technology but RSC makes it trivial to implement. Wrap the slow component in Suspense, add a fallback, done.
The DX problems are real though. Error messages are cryptic. "You are importing a component that needs useState. It only works in a Client Component but none of its parents are marked with use client." OK thanks. Now I need to restructure three files because I added a hover effect. And the mental overhead of constantly thinking "is this server or client?" adds friction to every decision.
My verdict after a few months: RSC is the right direction. The execution is still rough. If you are building content-heavy sites with islands of interactivity, RSC works great right now. If you are building a highly interactive dashboard, the constant server/client boundary management will make you question your career choices.
I do not have Stockholm Syndrome. I think. But I also said that about Redux in 2019, so take that with appropriate skepticism.