Server Components, A Working Hypothesis

The friction most developers hit with RSC is not a UX problem — it’s a mental-model mismatch.

We were trained to think in component trees where data fetching lives at the leaves, inside useEffect or React Query. RSC inverts that: data fetching lives at the trunk, in server components, and client components become the thin leaf layer that handles only interaction. The moment you stop trying to incrementally adopt RSC alongside your existing client-heavy patterns and instead treat it as the default boundary — server by default, client only when you need browser APIs or event handlers — the architecture starts to feel coherent rather than constraining.

The click happens when you realise the waterfall you were taught to fear is actually a feature: server components let you co-locate data requirements with the JSX that needs them, without sacrificing performance. The mental model stops being a fight the moment you let the inversion be the default.