The Broad Way

[ Sharp Mind · Sharp Blade · Sharp Spirit ]

root@construct:~
/react-server-components-actually-good-or-stockholm-syndrome
$_
<-- back to /logs
2026-02-22//LOG

React Server Components: Actually Good or Stockholm Syndrome?

I have been using React Server Components for a few months now. The blog runs on Next.js App Router. Some components at Yooga are moving to RSC. I have opinions and they are COMPLICATED. The mental model shift is real and it is brutal. For years, React was a client-side library. Everything rendered in the browser. Data fetching was a client concern. Then RSC comes along and says "actually, some of your components run on the server and they NEVER ship JavaScript to the client." Cool concept. Terrible learning curve. 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 though. They are genuinely good. Zero JavaScript for purely presentational components means your blog post page ships basically no JS. The data fetching story is CLEAN. You just async/await in your component. No useEffect, no loading states for initial data, no race conditions. The component runs on the server, fetches data, renders HTML, sends it to the client. Done. This is how it always should have been for read-heavy pages. Streaming is the killer feature nobody talks about enough. With Suspense boundaries, your page can start rendering immediately and fill in slower sections as they resolve. The user sees content FAST even if some data takes 2 seconds to fetch. This is not new technology but RSC makes it trivial to implement. Wrap a 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. TypeScript integration is getting better but there are still rough edges around async server components. 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 is 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.
The Broad Way | Kinho.dev