React Server Components (RSCs) aren’t brand new—in fact, they’ve been around for a few years now. So why are they still so misunderstood?

Like many React devs right now, I had a general understanding of what they were, but couldn’t have given you the details on how they work or why you might want to use them. As I’ve written about previously, I’m not generally an early adopter — I like to wait for a little bit and see how the practical use case of new technologies pan out. That being said, the future of React certainly seems to be trending toward server components; it was time for me to get up to speed.

RSCs are certainly a hot discussion topic right now, with many of the big voices in React really excited about them and confident that they’re the right direction for React to be heading...but that hype didn’t seem to be translating directly to major adoption in the community (myself, admittedly, included). That got me curious—not only about where that adoption gap was coming from, but also about what I might have been missing out on by not jumping on board sooner.

If you were like me—hanging out on the sidelines of the RSC movement, keeping an eye on stuff but not necessarily testing the waters yourself—you’re in the right place. Let’s take a look at the big picture regarding server components: not only what they are, but also why they didn’t take off immediately and the pros and cons of incorporating them now.

So, What Is a Server Component?

Within React, there are now two types of components: server components and client components. Historically, React exclusively used client components, so it might make the most sense to start there.

OK, Fine: What Is a Client Component?

The “client” in client components refer to the fact they they render and function entirely in the user’s browser—otherwise known as the client slide. Server-side and client-side refer to different places where the heavy lifting (if you will) is carried out in an application. Server-side stuff happens on the web server; client-side stuff happens on the client’s (aka user’s) device.

So when we wrote client components in React, it was with the assumption that all the functions, rendering, state management, etc. would happen exclusively in the browser on the user’s laptop/phone/tablet/screen on the front of their smart fridge/whatever.

Good to Know. Back to Server Components, Please.

Right. So, if client components do all their ish on the browser (aka the client side), then we can extrapolate that server components will do all their ish on the web server.

Traditionally, with client components, the component would send a request and wait for a response. That response would either be the data that we requested … or an error. If we got back the data, then that could be passed down to child components via props and rendered in the UI for the user. If we got back an error, well … we show the user an error message (hopefully).

In the meantime, it makes for a lot of waiting on the user’s side—a common complaint in modern app development. While that can be mitigated by lazy-loading, skeleton UIs, etc., those were still just bandages over the real problem—that apps are only getting bigger, and users aren’t always loading them with lightning-fast connections.

Server components run entirely on the server, which eliminates that back-and-forth game. The flip side is that their code won’t get included in the JS bundle—that’s a huge chunk of why the load times are way faster, but it also means that they can’t re-render when state changes. They do their thing on the server and then they’re done—that rendered component gets sent to the client side as-is, as HTML.

This means that any React app making use of RSCs would need a combination of server components and client components in order to be fully reactive to user inputs. Generally, you’ll want to reach for a server component when you need to do heavy data fetching or deal with big dependencies, then leverage client components when you need user interaction and stateful UI. This often looks like a parent-child relationship where RSCs are the parent and client components are the child. The Next.js docs have a really great breakdown of the different use cases where you might reach for a server component vs. a client component.

Will We See More RSC Usage in the Future?

Almost certainly. From a technical perspective: We know they’ll be included as part of the mainline, stable release in React 19 (although we don’t know when exactly that will come). From an adoption perspective: In addition to the endorsement of RSCs from several big voices in the React community, our most tangible indication of RSCs gaining popularity is Next.js.

What’s Next.js Got to Do with It?

Next.js is currently the only framework recommended in the official React docs that has full support for server components. So, why is that?

When the new React docs were officially moved out of beta in March 2023, it came with a big shift—frameworks are now the officially recommended approach for writing new React apps. Previously, frameworks were mentioned alongside a “roll your own” approach, with both being suggested as equally recommended approaches for new apps. Now, the docs specifically include several paragraphs on why using React without a framework is not the ideal approach.

One of the most popular React frameworks available (and the top-listed recommendation in the official React docs) is Next.js. Vercel, the company who maintains Next.js, has a close relationship with the React team — some have even argued too close. Setting aside whether it should be that way or not, that close relationship means that the decisions Next.js makes are closely interwoven with the decisions that React makes (and vice versa).

When Next.js takes an opinionated approach to something in their framework, it kind of comes with the tacit endorsement of the React team. In fact, Next.js is even built on the Canary (or early-release) versions of React instead of the Stable releases. While you can, without a doubt, still use React without Next.js, it’s getting hard to argue that they’re not becoming more and more enmeshed. Whether or not that’s the right move for the future of React is a different question—one I’m sure you can find several different hot takes on if you poke around, but which we won’t cover in this particular article.

That was a lot of context just to say: the choices that Vercel makes with regards to Next.js carry significant weight in the React world—and in version 13, Next.js made server components the default approach when spinning up a new app.

Developers can still, of course, opt out of this when using Next.js, but it takes a little config. Considering the amount of influence that Next.js has within the React community, it seems pretty darn likely that if Next.js is betting on RSCs, RSCs are gonna happen.

Why Aren’t More People Using RSCs, If They’re the Likely Future of React?

There are a few contributing factors:

Lack of Official Documentation

As of time of this writing, there is no guide to React Server Components currently included in the official React documentation. There are several mentions regarding the development of RSCs, plans for the future, etc., but no actual information about how and when they should be used. The most recent informational update about RSCs in the official docs is in a February 15th “React Labs” blog post, where they confirm that RSCs will be included in the next major version of React (but the actual release date of React 19 is still unknown).

There are some good guides out there to help new users really wrap their heads around server components — I especially liked React Server Components: A comprehensive guide by Chinwike Maduabuchi and Making Sense of React Server Components by Josh Comeau. Dan Abramov has also done a fair bit of tweeting about RSCs, offering guidance in a less-official capacity.

However, I would argue none of that is quite the same as real documentation.

Reliance on a Framework

Currently, server component implementation options are fairly limited — by which I mean that they need to be used in conjunction with a framework. A React Labs blog article on RSC development even says directly:

We generally recommend using an existing framework, but if you need to build your own custom framework, it is possible. Building your own RSC-compatible framework is not as easy as we’d like it to be, mainly due to the deep bundler integration needed.

So, while it’s technically possible, RSCs without a full-featured framework are currently more in the realm of weekend tinkering vs. real business-case applications.

That Framework Probably Needs to Be Next.js

The other piece of important information to acknowledge here is that when we say RSCs need a framework, “framework” effectively just means “Next.js.” There are some smaller frameworks (like Waku) that support RSCs. There are also some larger and more established frameworks (like Redwood) that have plans to support RSCs or (like Gatsby) only support RSCs in beta. We will likely see this change once we get React 19 and RSCs are part of the Stable version. However, for now, Next.js is currently the only framework recommended in the official React docs that supports server components.

So, if you didn’t happen to already be using Next.js for your React app, then your options for leveraging RSCs right now are pretty slim: either migrating to a new framework (which is no small task) or waiting for support in the framework you’re already invested in. As cool as RSCs sound, I can tell you which one I’d be doing (spoiler alert: it’s the waiting).

Should I Start Using Server Components?

The boring, logical answer to this is (like so many things in web development): “It depends.” It depends on your team, your current tech stack, whether you’re starting a new project or this would mean refactoring a legacy app, etc.

My personal opinion is that if I were in the lucky position to be starting a new project right now, I would probably do so with Next.js— and with server components. In addition to just being a helpful thing you can use to improve performance, I think there’s some real truth that the wind definitely seems to be blowing in the direction of RSCs — and that’s not a thing I would want to get stuck fighting against in the next few years.

However, if I were the maintainer of a current or legacy application, I wouldn’t make the jump just yet. I don’t think the support for RSCs are robust enough at this point to validate making the switch in an existing project. Would there be benefits? Sure. Would those benefits be worth investing such a chunk of time and effort into (what will almost certainly be) a huge refactoring project? My gut says no.

For many years, client components were the backbone of the React experience — and for the most part, it worked pretty well. To be completely fair, it still works pretty well; unless you’re experiencing pain points specifically related to using client components, then there’s really nothing that says you have to stop writing React apps using this pattern. I think it’s important to note that — unlike the switch from class components to functional components — new React developers are not (at this time) actively being discouraged from writing entirely client-side apps. In fact, apps leveraging RSCs are (again, at this time) significantly less common than apps exclusively using client components.

While it’s a safe bet that RSCs are in our future, we’re still a ways away from seeing them become officially “stable” in React. In the most recent version (18.2.0), they are still clearly marked as “experimental.” While we do know that they will be included as part of the stable release in React 19, we don’t know when that will be — and even once that happens, we’ll still see a lag between stability and adoption as frameworks, libraries and regular ol’ devs like you and me start to figure out what realistic incorporation looks like.

While some frameworks and libraries are getting ahead of the curve on this, it’s still nothing that could be considered widespread adoption. That means that true standardization of the RSC approach, figuring out good and bad patterns, and inclusion in the official docs are still — most likely — years away.