DX vs. UX: The RSC False Dichotomy

My name is Amy Dutton, as Scott said, and I am a Senior Design Engineer at G2I. And today we're going to talk about one of the most debated topics in the React ecosystem. It's one of my favorite things to talk about. And that is React server components. Specifically, why the industry conversation around RSC keeps shifting.

So let me tell you a little bit about where I'm coming from. For the past two and a half years, I've worked on the Redwood JS core team as one of the lead maintainers. And since I worked on a meta framework full time, I made it my job to know what all the other frameworks were doing. I figured if I was going to go to conferences like this one and say, Redwood is great, I needed to know why I thought Redwood was great and how it measured up against all the other frameworks.

Ultimately, we're all trying to solve the same problems. And I believe that the rising tide lifts all boats. So I wanted to be able to explain specifically what made Redwood different and why you might reach for it over another framework. So in 2022, we decided that we were going to go all in on React server components. Now, this was a big deal. If you know anything about Redwood, you know that it was originally built on top of GraphQL.

Surprisingly, a lot of you guys don't like GraphQL. That was a criticism that we heard often. And so listening to you guys, we decided to go all in on React server components. So the engineers on my team spent the better part of two years diligently plugging away. So why was it so hard? Well, there are several factors at play. First, framework code is not the same as application level code. In my mind, framework code is next level programming. And I can say that because I didn't write the framework level code.

Frameworks exist and solve a really hard set of problems so that the rest of us don't have to. When it comes to implementing React server components, it's not just a switch that you can turn on or off. You can't just upgrade React. And now you magically have React server components in your project. Unfortunately, it's a little bit more complicated than that. And so once you have React server components, you also have to have server side rendering to ensure that everything is rendered, sent down from the server properly. And then you also have to think through hydration and caching and server actions and functions.

So React might be well documented, but all of the pieces that you have to set up on the back end to make this technology work are not documented. Or at least they weren't in 2022. But it's not just React. So with Redwood we used Vite. Next.js for context uses TurboPack. So it's not like we could just copy and paste the pieces and parts that we needed from Vite weren't documented either. And so we were really solving problems that had never been solved before.

Let me add on just a few more layers. Redwood.js was started in 2020. And one of its appeals that we had first class support for Storybook, Prisma, and Jest. And so we tried our best to maintain all of those integrations. And so you can imagine that it was difficult to achieve that backwards compatibility. Then another layer in 2024, so almost a year ago exactly, Tom, who's the original owner, he handed everything over in the project to Peter Pistorius. And one of the interesting things about Peter is that he lives in South Africa. So a lot of the problems that he's trying to solve in terms of performance and delivery are very different than a lot of the problems that we're trying to solve living in the United States.

So Peter decided to start over completely. So he started with React server components from the beginning and went all in on Cloudflare services. In fact, in a React conf last month, they announced version 1. So until I started building on top of the new version of Redwood called Redwood SDK, I never really experienced React server components outside of Next.js. One of my projects at Redwood was to help write the documentation. I didn't realize until I started writing the docs that a lot of the features that I thought were Next.js specific were actually React features. And this whole experience gave me a completely different understanding and appreciation for the problems that React server components solve.

On one side, we have the developer experience. And on the other side, we have the user experience. And it seems like we're asking people to make a choice. But I'd argue that's a false dichotomy. So what is a dichotomy? It's kind of a fancy, weird word. Well, dichotomy is a division or contrast between two things that are represented as being opposed or entirely different. Really what that means is you have a false choice. So in our case, with React server components, we're not really choosing between the user experience and the developer experience. That's a false choice. And framing it that way misses the point.

I'm not saying there aren't tradeoffs. There are always tradeoffs. With every tool, every pattern, every architectural shift comes with them. What I am saying is that with React server components, we're talking about using the wrong tradeoffs. We've been framing the conversation in a way that makes developers feel like they're choosing sides, when in reality, most teams are just trying to build good products and choose the right tool for the right job. And that brings me to you guys, because most of you aren't maintaining a framework. You're building features. You're shipping to customers. You're fighting deadlines. You're dealing with legacy code.

And you're trying to figure out, is RSE something you need to care about right now, or is it something that you can safely ignore for another year? To answer that honestly, let's zoom out a little bit from my experience inside the framework and look at what's actually happening across the wider React ecosystem.

So React server components really sits in this interesting space. They're powerful. They solve real architectural problems. They simplify data dependencies. They reduce JavaScript. They improve performance in ways we've been trying to achieve for years. So if RSE is so powerful, why has the community struggled to adopt it? And why does it spark so many heated conversations?

It's not because RSE is bad. It's not because the developer experience is terrible. And it's not because the mental model is too hard. It's because RSE is one of the only React frameworks features in a decade that didn't ship through React. It actually shipped through a framework. Think about it. This is kind of unusual. Most React features land inside the React project, the package. You get the docs. You get examples. You get ecosystem agnostic guidance. That didn't happen with RSE.

Instead, it really arrived inside of Next.js. It was supported by Next.js Router, Next.js Bundler, Next.js Runtime. Not because of gatekeeping, but because RSE required a whole stack of infrastructure that only one framework adopted early. So whether RSE felt exciting or intimidating, it had nothing to do with React and everything to do with where you actually experienced it.

So if you worked in Next.js, RSE felt like a natural next step. If you didn't, then RSE felt inaccessible and something that you could read about but not actually try. And so that asymmetry has created some confusion. RSE wasn't confusing, but the ecosystem path to it was very narrow. People weren't debating React server components as a technology. They were debating build system requirements, routing assumptions, server runtimes, framework conventions, cache defaults, and the perceived cost of adopting all of that.

Even after you separate the technology from the ecosystem, there's another layer that shaped how we all talked about RSE. How RSE felt to developers in practice. Because the moment you put RSE into real workflows, whether that's inside Next.js or another environment, the conversation shifted from what RSE is to what it actually feels like. React server components does something unique. It asks to think about differently where your code actually runs. Most of us grew up with this idea that everything runs in the browser. With RSE, that shifts. Some components run on the server, some run on the client, some run on both, and they all collaborate.

Most of us grew up with this idea that everything runs in the browser. With RSE, that shifts. Some components run on the server, some run on the client, some run on both, and they all collaborate. This is a mental model change, but it's not a bad one. It's just different, and the difference is felt more acutely when you're actually developing. And here's why that perception gets skewed.

The user experience benefits of RSE, things like better performance, less JavaScript, faster initial load. They're all real, but they're largely invisible during development. I don't really feel that better performance when I'm on my local computer. You don't feel them in your editor. What you do feel are the day-to-day differences. You're learning the server and client boundaries. You're working with use server, use client directives, adjusting how data fetching works, understanding the cache layer, adapting to streaming and partial rendering.

These are all tangible. These are the things that you notice when you're developing, and this shows up immediately. So our DX conversations were happening through the lens of a single framework, not the lens of itself. It wasn't that RSE hurt DX. The real split, this one that we're talking about, this is the one that actually matters, is that RSE as a React capability versus RSE as a framework-specific feature. Everything else flows downstream from this distinction.

So let's go back and talk about what was actually the original promise of RSE. The pitch was pretty simple. We are going to move work to the server. The server is better and faster at processing. We're going to reduce hydration. We're going to stream the UI. We're going to avoid data waterfalls. We're going to simplify client-side state, and we're going to ship less JavaScript. The best part is we didn't have to learn a new thing. It was all React. You're just using components. You kind of get all this stuff for free. That was the dream.

But the dream wasn't always as simple as the implementation. Under the hood, RSE isn't just a React feature; it's a whole ecosystem of tools working together. To make RSE work, you need a server runtime, a router that understands server boundaries, a bundler that can classify components, a compiler, a streaming pipeline, and a serialization protocol. For a long time, only Next.js had all this infrastructure in place. RSE requires deep coordination across React, the router, runtime, and build system. RSE really only lived in one framework if you weren't in that ecosystem.

If you were in that ecosystem, RSE felt normal. If you weren't, it felt out of reach. This bottleneck shaped adoption, perception, and even the narratives around developer experience because the ecosystem hadn't grown around it yet. When you strip away all the ecosystem and perception stories, you're left with a fundamental question that every team eventually asks: What makes adopting RSE hard? React apps evolved around a different architecture for almost a decade. Everything resided in the browser. Routing was client-side. Data fetching occurred after render. Global state managed the gaps. The build pipeline didn't need to consider server boundaries.

Global state handled the gaps. And the build pipeline didn't need to care about the server boundaries. And it worked really well for the web at that time. So when React server components entered the picture, most teams weren't responding to RSE itself. They were responding to what RNC implied.

RSE shifts the center of gravity of your application from the browser back to the server. And when that center moves, everything else has to move along with it. The data, the routing, the caching, the file conventions, the rendering semantics. You can see this even in Next.js, which they basically had to create a framework inside a framework, the app router, to make RSE possible.

They didn't make the app router just to, I think we'll reorganize the files. They did it because the old architecture wasn't built around RSE's assumptions. And honestly, we had to take a similar path at Redwood too. For two years we tried to figure out how to retrofit RSE into our architecture. It was really never designed for it. We kept hitting walls. And at some point, we realized the easiest way forward was just to start over.

To rebuild the framework with React server components at the center, rather than trying to bolt it on to the edges. And that's what it means to adopt RSE. Not switching a feature flag, but reorganizing an application. Or in our case, a framework around a source of truth. So, RSE works best when your framework fully embraces it.

Developers shouldn't need to think about all these pieces. Because developers do depend on whatever steps that framework has taken or not. That's, I think, where developers and teams feel stuck. They like RSE, they see it, but the framework that they're using hasn't necessarily evolved yet.

Or adopting RSE would mean an entirely different stack than the one they're already invested in. So, the barriers aren't really about React. They're about architecture, timing, and momentum. But I would argue friction isn't failure. It's the natural side effect of shifting an ecosystem towards something fundamentally different.

Something fundamentally better. So, that friction only matters if there's something meaningful on the other side. So, the next question is, once you do get RSE into your stack, what does it actually unlock? The short answer is, RSE makes React applications behave the way we always wished they would.

React's server components quietly shifted the responsibility of heavy lifting back to the server. The place where it was really designed for. Suddenly the client doesn't need to hydrate everything. It doesn't need to orchestrate as much state. It doesn't need to fetch in a dozen different places just to render on the page. The UI becomes lighter. The Java bundles become smaller.

And your application starts to feel less like a single page app fighting the browser. And more like a web application that works within the browser. RSE simplifies the mental model of where code lives. You have server-only code that stays on the server securely. You don't have to worry about your API keys. You have client-side code. It's only for interaction. And because that boundary is more explicit, the application naturally avoids shipping sensitive information and unnecessary logic to the browser.

RSE nudges teams back towards the fundamentals of the web. It's not React becoming more complicated. It's React kind of rediscovering the strengths of the platform it runs on. So, these payoffs are real. And if the payoff is real, then the architectural shift is worthwhile. And so the question becomes, how do we get the rest of the ecosystem there? Because for RSE to reach its full potential, React can't do it alone. And Next.js can't carry it alone.

What has become clear over the last two years is that RSE thrives when it's surrounded by a framework ecosystem that understands it. Not just the what of the feature but the why of the architecture behind it. The success stories we've seen all share the same pattern. They treat RSE not as a bolt-on optimization but as a foundation idea. So, to get there, frameworks need to embrace RSE at the architectural level. They need to align their routing, their rendering pipelines, their server runtimes, and their build systems all around the contract that React expects.

This doesn't mean duplicating Next.js. It means making their own decisions about how RSE fits into their story on their terms with their strengths. And I think we're getting there. This is a screenshot taken from a site called Can I Use RSE Today? It goes through all the frameworks and gives you the current state. So, the QR code at the bottom of the screen will take you directly to that site. Other frameworks that aren't mentioned here, TanStack, Start, there's a basic RSE example within their release candidate. Remix, too, has shifted all of its features to React Router 7 where there's experimental support for RSE.

And my point is that when frameworks support RSE well, something pretty remarkable happens. Developers stop thinking about RSE as a feature and they start thinking about it as just this is how React works. The abstraction does its job, but frameworks can't be the only piece. We have to have tooling, documentation, testing libraries, debugging workflows, and hosting platforms. They all need to evolve alongside this new model. Developers need to see examples outside of a single framework. They need patterns that work no matter where they build, and they need a shared vocabulary, not a framework vocabulary.

We're talking about RSE. We also need something that hasn't existed until recently. We need that ecosystem variety. We need multiple frameworks implementing RSEs in different ways for different kinds of users on different runtimes and using different build tools. Not so we can compare them, but so the community can actually understand what RSE is independent of any single implementation. And finally, that conversation needs to shift. We spent two years talking about RSE through the lens of friction, but as frameworks adopt RSE natively, those edges become clearer, the pitfalls become rarer, and DX stops feeling experimental.

RSE doesn't need a better pitch. It needs a broader foundation, and so when that foundation is in place, the DX versus UX debate doesn't just disappear. It really becomes irrelevant because developers won't be choosing between performance and experience. They'll be choosing between frameworks that all understand that same core idea, that React can be fast, expressive, server-aware, client-smart, all at the same time. And that's the future that RSE is moving towards, and it's one that we're finally starting to see take shape. So that really brings us full circle. So after looking at the history, the perception, the architecture, and the reality of RSE, here's the real takeaway. React server components were never about choosing between developer experience and user experience.

They were never about rewriting everything you know or being locked into one framework or learning a whole new way to build. RSE is always about React, a way to align more closely with the platform, about sharing work between the client and the server without forcing you to reinvent the entire app, about making the web feel fast again without asking you to dig through kilobytes of hydration code.

And as we unlock that future, when we stop framing DX and UX as competing goals and start treating RSE as what it truly is, it's an ecosystem effort. The more the ecosystem embraces RSE, the more natural and powerful it becomes, not because RSE changes but because everything around it is finally able to catch up. We're getting there. This is in reach, and let's do it together. Thank you.

One question right now, which is, what is the least risky RSE experiment you would conduct in a legacy enterprise React app? That's kind of a gotcha question because it depends. I'm assuming if it's an enterprise, you're using Next.js because that's really the most production ready framework, even though more have started to adopt it. And so the thing about Next.js and RSE is you can actually run it within the pages directory and the app directory. You can actually have both within your application, and so you can start to move pieces over slowly as you want those benefits. And I would focus on the pages where you want the more server side aspects of that. So whether that's handling complex data fetching, mutations, things like that, or it's something that you want that SEO, the OG tags, all those pieces.

Yeah, nice. OK, I've spent a lot of time trying to lean into RSE, but I've disliked having to think about where the data is being queried from and how to manage app state between the client and the server.

How does the Redwood SDK handle this? Also, why Cloudflare? Why Cloudflare.

So, what's interesting, let's see, you were talking about the data, how to manage between the client and the server. So I think some of it is once you realize what should happen on the client versus what should happen on the server. If you're grabbing data, my recommendation would be for that to happen on the server. You get the security benefits. You don't have to worry about API tokens or things leaking.

So Redwood SDK handles this, actually similar to Next.js, mostly because it's more of a React feature where you can just query within your page code. You can also do that within the client if you want to use a user factor, pass something down.

But the third part of your question, why Cloudflare? One of the reasons why I think that Next has succeeded and done so well is because it's tied so tightly to Vercel. You get all of these benefits where you have a hosting platform that's really designed to make Next.js run fast. And they've built up a whole ecosystem around that.

And so as we were working on Redwood, the first version of Redwood, we tried to be as agnostic as possible. And so we had tons and tons of tests to make sure that it ran on every single server and framework and platform possible. And so by picking one, we were able to move faster, but we were also able to guarantee that certain things would be available and certain things would work.

And then Cloudflare has so many things out of the box. I don't know if you guys are aware of that. You should go talk to the guys at the Cloudflare booth. But they have D1, which is a database built-in, so you don't even have to worry about stitching that together. You get that. R2, you have storage. Done. You have cron jobs. Done. You have background jobs and scheduling. All that. Done. You have hosting. Done.

And so when you're building in your local environment, it works just like it would on the server. You don't have to figure that out. It makes stitching things a whole lot easier, preventing decision fatigue. You don't have to decide what to use; it's all there and available.

What are the main benefits of using Redwood instead of Next.js? Well, the developer experience plays a significant role. Redwood's router differs with a configuration router similar to React Router 7, offering benefits in route changes without file movements. Redwood's middleware handling stands out, providing a clear picture of when middleware and interrupters run, unlike Next.js's middleware file approach.

One thing I miss about APIs while transitioning to RSC and Next.js is the visibility of clean request-response JSON payloads in Chrome DevTools Networks tab.

So some of the things that Redwood has done that's a little bit different is their router is very different. They have a configuration router. If you liked React Router 7, you'll probably like Redwood's router. They're very similar. They've taken a lot of the same patterns, whereas Next.js is a file-based routing system. So if you want a new page, you just create the page, create the file, like there it is. So it's a little bit different.

In my opinion, there's some benefits to having that page-based, like configuration-based routing system. You can change routes without having to move your files around. But one of the key differences, I would say, that most people appreciate with the Redwood system is how they handle middleware. So if you look at that router config, and this is why I kind of brought it up, is that it's essentially an array of parameters that you're passing in to say if you go to this route, deliver this component. But they handle middleware and interrupters.

They're kind of the same thing. Middleware runs before every single page. Interrupters you can say, I just want it to run on certain pages. But you get this clear picture of when the middleware is running and when these interrupters are running and then when it's loading the page. Whereas with Next, that's actually done through a middleware file.

And so sometimes at least when I've built Next.js projects, sometimes I've forgotten about middleware. I'm like, why is this not working? And it's because it's hidden in this side fold file. They're like, oh yeah, it exists over here. Thanks for the very cool RSC framing. One thing I miss about APIs now that I'm starting to use RSC and Next.js is seeing clean request response JSON payloads in Chrome DevTools Networks tab. Any tips on RSC debugging tools?

Yeah, I don't have anything specifically, but I will say kind of the gotcha there when you're trying to do debugging is like, where is this coming from? You'll log something out and it's not in the browser console. Where is it? It's in the terminal. It's because it ran on the terminal and not the browser. But one thing that I would say, if you like the clean request response JSON payload, look at Redwood because they've tried to make it very clear that this is the request that we're putting in and this is the response. So you can have it respond with a React component.

You can have just a normal HTTP response. You can just stick that back in the browser. You can send in text. And so it makes it very clear and easy for beginners to understand this is the request and this is the response that you're going to get back. Awesome. Well, thank you so much, Amy. Thank you.