React Server Components have been in my production stack for about two years now. The mental model took longer to click than I expected. The end result is that I’m using them more carefully and in fewer places than the early hype suggested, but where they fit, they fit very well.

What I’m using server components for: data fetching at the page or major section level where the data is request-scoped, secret-handling for API keys and credentials that shouldn’t reach the client, large component trees that are mostly static and benefit from server rendering without hydration, and integration points with backend services that don’t have clean public APIs.

What I’m not using server components for: anything truly interactive, anything with rapid state changes, anything where the user expects immediate feedback on input. Client components remain the right answer for these. The fact that you can mix them within the same page is the actual win, and getting comfortable with the boundaries took me months.

The pitfalls I hit early: serialisation issues where a non-serialisable value crossed the server-client boundary, hydration mismatches where the server-rendered HTML didn’t match what the client expected, and over-zealous use of “use server” actions that tried to handle interactive flows that should have been client-side.

The framework choice matters more than the abstract feature. Next.js App Router is where I do most of this work. The framework’s opinionated structure makes the server-client split visible and forces you to think about it from the start. Other frameworks have implemented similar patterns and they all work, but the Next.js path has been the smoothest for me.

The development experience has improved meaningfully through 2025 and into 2026. The error messages are better. The dev tools have caught up. The community has produced enough patterns and examples that you can usually find a precedent for whatever you’re trying to do. The early days when you’d hit an error you’d never seen before and have to read the React source code are mostly behind us.

Performance: real but variable. Server components reduce client JavaScript bundle size for pages where the interactive surface is small. The benefit is most visible on first load and on slower networks. The benefit is less visible (and sometimes negative) on highly dynamic pages where everything needs to be a client component anyway.

For developers picking up server components in 2026, the practical advice has settled. Read the official docs first, not the third-party tutorials. Build a small project end to end before trying to retrofit a real application. Pay close attention to the boundaries you’re drawing — every “use client” directive is a decision worth thinking about, not a syntax requirement.

The longer-term direction is interesting. The split between server-driven and client-driven UI rendering is going to keep evolving. The core insight that the right rendering model varies with the use case is settling in across frameworks. The era of “everything is a single-page app” is genuinely over, and that’s a healthier place to be.