React Server Components (RSCs) were touted as a way to make apps faster by doing more work on the server and sending less JavaScript to the browser. In practice, there are real cases of performance wins. For example, one company rebuilt a Next.js site with RSC and saw a 62% reduction in JS bundle size and a 63% improvement in Google’s Speed Index (meaning content became visible much faster). This happened even though the total HTML sent was larger; the key was that the RSC version sent almost no client-side React logic for those parts, so the browser had much less work to do and achieved first paint sooner. Similarly, the RedwoodJS framework found that by removing GraphQL and using RSC for data fetching, they avoid a whole class of network overhead (no more N+1 GraphQL requests or extra round trips) and eliminate that performance penalty. In short, RSCs can dramatically cut what the client must download and execute, which translates into faster loading in many scenarios.
That said, the benefits are not automatic. Early adopters discovered that naive use of RSC could lead to stale data or unexpected caching issues. Next.js’s initial RSC implementation aggressively cached fetch requests by default (to maximize performance), but developers found this confusing when data changed. By the time Next.js 15 rolled out in late 2024, the framework dialed back the magic, fetch calls no longer cache by default (no-store became the default), and even route handlers and client transitions avoid caching unless you explicitly opt in. This change acknowledges a hard truth: performance improvements from RSC must be balanced with data freshness and developer control. Today, frameworks are still refining these knobs. The bottom line on performance is that RSCs genuinely can improve real-world load times (sometimes spectacularly), but you have to use them thoughtfully. If your app is heavy on data-fetching and you can render much of it on the server, RSCs will likely make it snappier. If, on the other hand, your app is mostly interactive client logic or you’re calling numerous separate backend services, the speed gains may be more modest. In those cases, RSC might behave closer to traditional SSR in outcome, and you’ll need to measure to see if it’s worth the complexity.
Performance aside, do RSCs make life better or worse for developers building real apps? Here, the story is mixed. On the one hand, RSCs can simplify certain workflows. RedwoodJS’s core team switched their default architecture to RSC primarily to improve developer productivity. They concluded that the overhead of setting up and reasoning about a full GraphQL API (their old default) was slowing developers down more than it helped. By using RSC for data needs, Redwood devs can call server code directly from components and skip writing GraphQL schemas/resolvers for every little change. The Redwood team felt “the benefits of switching to RSC-by-default were just too good not to make it the default…” as it aligns with their goal to maximize developer productivity. In practice, with Redwood, one can now fetch data by invoking a service function on the server, and immediately use it in a component, without juggling a separate API layer. That’s a tangible DX win in contexts where building an API is overhead you don’t need.
On the other hand, RSCs introduce new complexity and mental overhead that developers are still grappling with. The very first thing React developers must learn is to split components into “server” or “client”, and this decision has to be made for every component you write. This feels foreign because for the past decade, React devs just wrote components (all running in the browser) without that concern. As one frontend developer put it, “Every time I made a component I had to decide if it’s a Server component or a Client component. The extra cognitive overhead is non-trivial.”. Especially in a larger codebase, constantly reasoning “can this be a server component or does it need to be client?” adds friction. Many developers have found themselves defaulting to client components out of habit or to avoid bugs, essentially forfeiting some of RSC’s benefits. There’s also the boilerplate annoyance of sprinkling "use client" directives all over your files to opt into client-side behavior. It can feel like the model is “upside down”. Why are the most common interactive components the ones that need an extra annotation? This inversion hasn’t sat well with everyone, not yet.
Handling user interactions remains a pain point as of 2025. Simple things like forms require new patterns (Server Actions in Next.js, for example). Instead of a straightforward onSubmit handler in the browser, you might write an async function with a special "use server" directive and wire it through a form’s action attribute. It works, but the aforementioned author also remarked that it feels bolted on: “the hoops you have to jump through just to submit a normal form using RSCs” suggest forms were an afterthought in the RSC design. Until frameworks smooth this out, building rich interactive features with RSC can be more involved than the old client-side approach.
It’s not all negative. Teams report that after climbing the learning curve, the separation of concerns becomes clearer. You naturally begin fetching and assembling data on the server, while keeping the client side strictly focused on interactivity. But there’s no denying the learning curve. Early adopters found that traditional React mental models didn’t neatly apply. Developers had to rethink how they structured apps to fully benefit from the new approach. Crucially, many discovered that a pragmatic stance worked best. If something became overly complicated with RSC, they’d simply “fall back” to a client component and move forward. This flexibility is key. RSC isn’t an all-or-nothing solution. Knowing when to avoid server components can matter just as much as knowing when to use them. Day-to-day, RSCs are smoothing out certain workflows while complicating others, leaving developer experience as very much a work in progress.
Beyond benchmarks and code, RSCs are subtly reshaping how teams architect apps and how front-end and back-end concerns blur together. A novel consequence of RSC adoption is what one might call the “re-monolith-ification” of web apps. In the past few years, many projects embraced APIs (REST, GraphQL) and a clear separation between client and server. React Server Components, however, encourage a more fused approach. Your UI and data fetching logic live in the same project, even in the same file tree. RedwoodJS’s move is a prime example, they went from a strict two-layer architecture (React + GraphQL API) to collocating business logic with the front-end. Redwood still enforces some structure (you write your server logic in service modules), but it’s all part of the React app now, no separate API server required. This yields faster iteration for a small team (one deploy, one codebase, nothing serialized over the wire), but it also means that if you ever need to expose a public API or allow third-party clients, you’ll have to introduce that after the fact. Redwood anticipates this by providing a command to add GraphQL back when needed, but it illustrates the architectural trade-off: RSCs favor an integrated, monolithic architecture, at least initially. Teams need to consider if that aligns with their long-term needs. For a startup trying to move quickly with a unified team, it could be a boon. For a large enterprise with distinct backend teams or existing services, using RSCs might just mean your server components end up calling those internal APIs anyway, in which case, the complexity of RSC might not be worth it for that organization.
There’s also a human element. RSCs effectively ask front-end developers to take on more back-end style work (data fetching, handling secrets, orchestrating loading states on the server). Some teams will relish this full-stack empowerment, but others may have a hard time separating roles. If your front-end devs are not used to dealing with database queries or if your security practices forbid directly querying a database from the front-end layer, RSCs could clash with your team’s composition. In such cases, you might constrain RSCs to call your existing backend APIs (rather than raw database calls), which limits their benefit. Essentially, RSCs shine most when the same team (or person) is handling the full vertical slice of an application ( UI and data together). This is why we see frameworks like Next.js and Redwood targeting the “indie full-stack developer” experience with RSC. However, if you introduce boundaries such as an external headless CMS or a microservice, RSC simply becomes another way to do SSR. It won’t magically eliminate network hops outside your control.
One interesting shift in 2025 is that more frameworks outside Vercel’s ecosystem are now embracing RSC, which is encouraged by React 19’s stability. Gatsby and Remix(React Router v7) have recently added support, have recently added support, and we’re seeing broader adoption within the React community as developers increasingly view server components as the path forward. This growth positively influences tooling and best practices, which will help mitigate some of the complexities over time. As RSC usage grows, libraries are adapting, many UI component libraries now ensure their components can run as RSC or client as needed, and testing tools are starting to handle the dual environments better. Teams are sharing patterns for things like authentication, state management, and forms in an RSC world. These are signs of maturation. But it’s worth noting that here in 2025, we’re still near the beginning of that curve. Adopting RSC may have organizational ripple effects, influencing everything from how you plan deployments, given that server and client code are intermingled, to how you divide responsibilities between frontend and backend developers. These organizational considerations should be weighed alongside the technical benefits.
So, are React Server Components improving your apps? The most honest answer is, it depends on your app and your team. We have solid evidence that RSCs can deliver faster user experiences by cutting down on JavaScript and leveraging server-side power, the kind of improvements that are very hard to achieve with client-only React. We also see frameworks like Next.js and RedwoodJS betting on RSCs as the future, suggesting that even if RSCs aren’t a silver bullet for every problem, they offer enough advantages to become the new default in many situations. In new projects built in 2025, it’s increasingly common to start with RSC architecture out of the box, especially if using a framework that makes the setup seamless. Those apps are benefiting from better performance and a more straightforward data-fetching story.
However, experience has taught us that there is no free lunch. RSCs improve some aspects of development while complicating others. If your application is highly interactive with complex client-side state, you’ll still be writing plenty of client components and dealing with all the usual client-side challenges, plus the overhead of deciding where every piece of code should live. If your team is upgrading an existing app, RSCs might not be a justified upheaval unless you’re hitting a wall that RSCs specifically solve (for example, an unbearable bundle size or SEO issues that pure CSR can’t fix). And if your workflow or organization doesn’t align with the all-in-one approach RSCs encourage, you might find the payoff just isn’t there yet. Many have found RSCs to be most worth it for use cases like pages that pull in large amounts of data or use big third-party libraries that can stay server-side. In those niches, RSCs are a game changer. In more general use, they’re a nice tool but not a revolution across the board.
In 2025, my honest take is that React Server Components are incrementally (sometimes significantly) improving many apps, but not universally and not without cost. They are an important evolution in how we architect React applications, one that is likely to become more impactful as the ecosystem catches up and as we developers adjust our practices. If you’re a senior developer, the key is to approach RSC with neither hype-driven zeal nor cynical dismissal. Measure the impact in your scenario. Embrace RSCs where they solve a problem or improve an experience (faster loads, simpler code by removing an API layer, etc.), and don’t be afraid to stick with client-side components where they make more sense. The question isn’t “should I rewrite everything to RSC?” but “where will RSC make my app better right now?” By 2025, we will have enough knowledge to answer that with nuance. In the coming years, as patterns solidify, we can expect RSCs to improve more aspects of our apps more of the time. But as of today, they’re a powerful tool to be used judiciously, not a magic wand that automatically improves all apps. The savvy developer will cut through the hype and apply RSCs in the spots that count. In those spots, yes, RSCs are genuinely improving apps, sometimes dramatically so, and that trend is only set to continue.
If this piece was helpful or resonated with you, you can support my work by buying me a Coffee!
Become a subscriber receive the latest updates in your inbox.
Member discussion