React Server Components Panel Discussion

So, for our fantastic panel today talking about React Server components, we've got Tom Preston Webber, Andrew Clark, Catherine Middleton, Matt Carroll, Ben Holmes, and Josh Komu. Hey, everybody. Fantastic. So I'm going to do a combination of some stuff that we talked about beforehand, then get on to Slido and hopefully answer a few questions there too. We've got a lot of panelists and not a lot of time to talk, but let's get into it.

So is RRSE something every React developer should learn now? Yes. Yes. Absolutely. 100%. That's easy enough. More ideas? You want to dig down into that a little bit? I can start. I feel like RRSE, the fact that you get to use server components on the server or components on the server is insane. So you should learn how to use it. Just in general, it's really cool to be able to use server components. And I think if you're new to React or you're starting an application from scratch, totally check out RRSEs.

We are trying to incorporate RRSEs as part of our learn docs and incorporate it as the React paradigm. But if you're someone who is already have an application and wondering whether or not it makes sense to use RRSEs, I think it could help with a lot of use cases. Especially if you're using a lot of data or a lot of things on the server side. It's totally worth learning RRSEs. Does anyone disagree with it? I'm curious. On the panel? The only thing I would say, I think if you have an existing application, you shouldn't feel pressured to start converting it. You know, current, like, every component we've ever written until now has been a client component. And so there's no big urgency.

But I do agree that it's a really cool feature and if I was starting a new application today, I would definitely... But if I'm doing a create React app, you should start that today. Or a VT app. It's completely spa. Is there anything that I'm gonna get out of React server components? Or is that just mostly when it's gonna be, like, NestJS? It's really about having the possibility to choose from the best world of a multipage app and a single page app and combine them together. So it's about choice. So I think to not learn is to be ignorant by choice. None of us want to be ignorant by choice, right? So learn them so that you know whether you want to use them or not. But at least learn what they're capable of.

I would also... Oh, so you wanna go, Matt? Yeah, I just got to say that when you're starting... If you start with server components, you can build a single page app. But if you don't start with a server component compatible framework, you cut yourself off from being able to leverage the server later on without having to do a very rough rewrite. So there's plenty of examples of people building complete client-side applications that just deploy to a CDN, building with a server component framework. And if they ever do decide to leverage the server, it's just one component. You might have some infrastructure you need to work with. But as far as a migration on the React side, you don't need to do anything.

I was gonna add... I think there's an implied premise in that question, which is that server components are additional complexity to learn, especially if you're starting out. And I think that is true if you already have an app. If you already have an app, it is just an extra thing to put in your brain. It's an extra pattern to learn. It's just more knowledge, so more complexity. More is more. Yes. But the idea, though, is... And I think for folks that are just getting started out, they're gonna have an easier time, because what do you get to unlearn if you do have server components? I don't know if you all are aware of server actions, but server actions is an example of something where if you use that pattern, maybe I don't ever have to write an API endpoint. That's not that appealing to someone who already has a bunch of API endpoints, but if you kind of wipe the slate clean, I think there's an argument to be made that that's just way simpler. Is using React server components properly... Is server actions part of that? In order to use RSEs properly, should you also be using server actions? Because they are somewhat controversial, but then RSEs were also controversial.

Very new. Yeah. I do think that they are necessary for the mutation side of things. If you don't know what that means, it's like React forever has been... You ship everything to the client, and if you want to fetch something, well, use query, I guess, because use effect is scary. And there hasn't really been an answer for, I need to go back to the server and get more stuff. And server actions is that answer, to get more stuff. It injects into forms really nicely, so if you just have a form set up, you can wire it to an action, and you can expect any submission to that form to go to your server. So it feels like the missing piece that React has needed when you want to treat it in a full stack kind of way. That use query and tRPC have filled up until now. And I've also learned you can use tRPC in a way to kind of bridge client fetches and server actions, so there's a lot of ways to kind of adopt into it. It is very new, though. I know it was experimental for a while, and there's some closure things, bundlers, tainting object references. I feel like there's best practices to come out of the primitive that are still being worked on, but it feels like it's going the right way, having it in React Core especially.

Yeah, fantastic. Yeah, fantastic. And here's a Slido question, so be sure to put in Slido the questions you want answered and up-vote the ones that you like. Doesn't streaming prevent server-side caching, and wouldn't it be better to be able to also use RSEs as a pure server-side rendering technology? So by pure server-side, do they mean not streaming and trying to render it to HTML? Because I don't know what pure means. When it is being rendered from the server still, it's just straight down the results as it goes. I don't know, does anyone want to expand on that? Yeah, I don't know if I 100% understand the question, but I'm going to pretend it means a certain thing. Does streaming, is streaming incompatible with caching? Sure. Because usually the thing that you cache is not a stream, it's going to be like the full buffered result. I will at this point plug partial pre-rendering, and the idea behind partial pre-rendering is to get the benefits of both. This is an experimental next thing, but it's built on primitives that are in React, and so other frameworks could take advantage of the same pattern. And in partial pre-rendering, by the way, I invite you to just google that term or go to partialpre-rendering.com to see the demo. The idea is that you're going to cache as much as you possibly can throughout the server components tree until you hit something dynamic. And then when you visit the page, you're going to get the benefits of caching, where everything that was cached, using essentially the ISR pattern, everything that was cached can be instantly delivered, the same way that you would instantly deliver a regular asset from the edge. And then simultaneously, in parallel, you can stream in the dynamic parts. And that's how you can get the benefits of both. And like Tom was saying, the idea with all of these API designs is you want to have as much as possible, you want to have a single paradigm, a single architecture that allows you to very easily and in a compositional way take advantage of these different benefits.

I think in the previous worlds, when you had to use SSR, when you were using SSR, you had to choose at a pretty high level how you were going to think about your server-side rendering. And a lot of what server components let you do is bring that scope down from a route or a larger level down to the component level. React gives us primitives to choose how we treat each individual component. So just like Next is doing with partial prerendering, React has the primitives to let you statically cache an individual component and send that HTML. And then for other dynamic components, you can use RSCs to update just the components that you need to. So React today has everything you need to do to do, I think, the best of both worlds when it comes to streaming and caching.

I would also say that partial prerendering is really exciting. It's been the gold standard of mine for a long time to figure out how to have the best of both of these worlds. I wrote a blog post about hydration. To avoid hydration mismatches for any sort of dynamic data, you have to leave a hole in your application, and then you have to wait for React to hydrate on the client, you have to do a re-render, you have to fetch any data that you need. And all that takes a lot of time. So it is really cool, the idea that the server can shoot away, or even have a cached HTML file that includes all the generic stuff, but it's still working as you're downloading that HTML and React is getting set up and you're just shooting along the dynamic data as soon as possible. It unlocks the sort of thing that years ago I was yearning for, so I'm really excited about it.

Alright, well the audience has a fantastic question that I really want to ask y'all. So, for a regular internal corporate app, do you think RSE is offering anything over, say, a SPA model? I definitely do. So my whole argument is, and this is kind of what I was trying to get at earlier, is that RSEs are just way simpler. And it might take a year or two or some time to convince everybody of this, but I don't think that building an app with one of these modern meta-frameworks is harder than building an app with Create React App. I think it's easier. Again, server actions is just, I know there's some controversy, but if you give it a shot, I think, and keep an open mind, it's just way simpler than not using server actions. It's just so much less plumbing and so many fewer little bits that you've got to stitch together to get something basic working. If this idea, if this vision of server components enabled apps being simpler than the old SPA style is not true today for everyone, then maybe we have some work to do. But I think that is the assertion and that is the future we're trying to build toward.

I agree. The mental model of server components really is much simpler. If you think back to some traditional multi-page application kind of frameworks like Ruby on Rails, et cetera, it's very easy to think about how that works. You have a server. You fetch some data on the server. You produce a page and deliver HTML to the client. And that's kind of the whole thing there. And then you might layer some JavaScript on top.

Well, React server components allow you to do the same thing, but now fully with React, choosing where your boundary between the server rendered and the client rendered functionality goes. But as far as data fetching, you can really, really simplify that model. And instead of having to fetch data over the wire and send that down or split it up, or if you're doing one single action at the very beginning to feed all that data into your component tree, just fetching the data on the server, putting it into a React server component for display, you can do very simple things simply. And I think that should be a goal that we all have.

I don't think you should be looking at general categories of projects and say server components are good for this or that. You should look at the individual constraints of your project. Providing a broad recommendation for internal corporate apps is really hard. But if you already have an internal app that's working with Create React app, and you don't have any problems with it, I don't feel like you need to use server components just to use server components. But if you're encountering some problems with bundle sizes or some latency making network requests from the client that would be better served making those requests from the server, that could be something to look at.

Or if you're starting fresh, I do agree with everyone that this is the best place to start. Can I give a counter argument to everything we've just said? Which is I think the biggest reason you would maybe not use server components today is you're not running JavaScript on the server. That is a realistic. I mean a lot of folks are just they have Python apps, backends, they have Rails backends, if you can't run JavaScript on the server then, well, maybe consider running JavaScript on the server. But if that's not an option, then look, don't feel like you're doing something awful by continuing to use Vite or one of these other classic methods of building a React app.

But I do think, I had mentioned earlier that honestly while I do think just running JavaScript on the server is worth it to get all these other benefits, honestly I am a little bit excited by the idea of someone building an RSE runtime for Python or something like that. I think that would be really cool where you just write Python that sends down client React components and everything else would be essentially the same. But that would be cool if someone built that. I think someone built a Go version of this, right? Yeah. It was like an experiment. That's cool. See, I think that is a valid reason not to use server components is just it's a technical limitation.

Another one is React Native doesn't have a server components implementation yet so you still have to use traditional methods there. And then another one is that, you know, a lot of times I fall into this trap of describing like the idealized world where everything is adopted this pattern and all of the kind of concerns and features that we want to build have already been built. But another example that comes up a lot is like local first apps where you don't have to do a server round trip every single time you want to navigate. Current frameworks don't make that possible or at least easy. But maybe in like a year or two that stuff will be built out. So it is important to like separate our idealized description of what we want the world to look like from what's actually been built today.

I do hope that people understand that even the parts that aren't there yet, we can make better on this architecture. Also RSEs are opt-in, so don't feel pressure to use RSEs. Client apps are not going away. Yeah. And I noticed the way suspense and other patterns work are the same. So if you have like a client-side suspense app where you're querying and pushing things can kind of turn into a server component expected to work the same way. So it doesn't feel like a refactor needs to change the way your React code looks or the way it's structured. The only difference is now your root needs to be server-side, which is why it's harder to adopt later.

If I could just add one more point to that, which is I meant to say this earlier. Most of these features that we've talked about like server actions actually do have a client equivalent. So we haven't really talked about this so much in the docs and stuff because, you know, one thing at a time. The action API where you pass a function to a form, that works just in regular React. You pass a function and you do like some sort of mutation, it could call into an API endpoint and that does work in React now. The idea is that, you know, going back to this idea of single unified programming model is that the same patterns that you use on the client are also used on the server and as much as possible vice versa. You can't be doing a SQL injection in your action on the client, but the programming model should be the same. So we do really try, and we get heat for this sometimes too, we do try to make the same features available on the client as well so that you have that unified model.

And the other important point is all those work and can be composed together, so you can have a client action that validates a form on the client and then also have that call a server action that does further validation and actually performs whatever task you want. So that's one of the biggest benefits too with all these different primitives we have is we've done a lot of work to make sure they work very well together.

What is planned to make RSCs non-dependent on Next.js having a documented API to access a server and client parts? A big part of how we're facing this at Redwood is right now it is a little challenging. Things are not fully defined but part of the work that we take upon ourselves is to help the React team, Matt's been amazing at this, is to really unravel where those boundaries are, where they need to be better documented so that everyone in the ecosystem and this community can understand those boundaries and have much more well codified documentation. And we can all create implementations and push React and the future of React forward together. That to me is how we all win.

I think another lens to this is to consider how would you adopt server components if you're a company like Meta or you're a company like Microsoft. You're not running Next or Redwood probably, I mean I can speak for Facebook because I used to work there, but incredibly sophisticated bundlers and infrastructure that is not the same as the off the shelf stuff that we use in the open source community and Meta is in the process now I believe, someone can correct me, of looking to start to integrate server components into their highly sophisticated largely relay based infrastructure today. And it should be possible for not just Meta, but for any other corporate environment like that to adopt this technology and so in addition to enabling the Redwoods of the world, that's another thing we have in mind.

That to me is how we all win. No tool is going to be perfect for any job. The important part is that we have great tools that solve individual problems that you can apply when those problems are your problems and we do that together as a community.

I think another lens to this is to consider how would you adopt server components if you're a company like Meta or you're a company like Microsoft. You're not running Next or Redwood probably, I mean I can speak for Facebook because I used to work there, but incredibly sophisticated bundlers and infrastructure that is not the same as the off the shelf stuff that we use in the open source community and Meta is in the process now I believe, someone can correct me, of looking to start to integrate server components into their highly sophisticated largely relay based infrastructure today.

It is complicated. There's a reason there's not just a five bullet point list of this is what you do is because it does take some engineering work to build one of these things. There's a reason why people don't just build their own web pack everyday or they build their own V-I-T everyday. I'm not going to say it's quite on that level, but it's complicated. It's complex and it's not like a one size fits all thing as Tom was saying. So that is a goal for us is to enable any organization with a little work to adopt the technology.

So that is a goal for us is to enable any organization with a little work to adopt the technology. I mean I think they could just watch Vince talk. We try. Yeah right, exactly. Yeah I feel like the impetus for that kind of question is like, how can we get to the same thing that happened with server rendering where I have an express server, I need to add server rendering, show me what to do, oh it's rendered to string, I can add that. It's a lot more than just core React APIs, it's bundler APIs. It's how you actually bundle the whole thing out because up until now React has been transpiled, you can turn JSX into function calls, that's easy enough to call Babel and do, but bundling a server component with a client component with a server child that has a server action, that requires even like cyclical bundling pads. I've talked with Vite way too much about this. Requires fundamental changes in how you think about bundling in order to support it.

So I feel like to adopt it on a larger scale it needs bundlers, Webpack and others, to have a system that is generic enough where you could call into it and say I'm a company, we use raw Vite, we're going to toss a server component at it and it has everything in order to bundle it out and gives us just what we need to plug it into an endpoint. It's a tough future to get to and it requires a lot of motivation across frameworks. For us to build it out so you can use it. So I'm glad Redwood's on that because you all use Vite and I know other teams use Vite too. Vite does not currently do what we need it to do but we hope that our efforts will make it easier for the independent businesses of the world to apply it in that way.

It's like oh, we'll just add this plug-in and put your components here and you know you're 90% of the way. I will say that there's a lot more to Redwood and Next.js than just that part though and slightly spicy. I don't recommend most people try to build their own server components implementation. What? I would suggest you. It's fun. For fun, yes. Unless you're good. 20 minutes. Unless you're good. I'm not trying to, I mean that's exactly the type of person I am. I want to take things apart but if your focus is not so much having fun but if you're building a product or you're at this company and your main goal is to deliver value to your customers, it's probably usually not the right route to go and stitch together your own implementation is to use one of these prebuilt frameworks unless you're at some place like, you know, Meta, Amazon, Microsoft that has really sophisticated requirements which is not to say you shouldn't watch these talks and get really interested in it but for most people, you should wait till the plugin exists or you should wait until these frameworks are adoptable and do that. Since I've joined the React team, I think I've focused a lot on what the React application developer experience is like with server components and server actions and now with server actions being in the Canary release and used by Next and Redwood and hopefully many others coming soon, like I'm hearing a lot more from the community that we need to know how to build libraries. We need to know how to build frameworks and, you know, Ben highlighted a few on his stream preparing for this talk and we've been talking a little bit about that. So my focus moving forward is going to be a little bit more on how to connect folks that are working on all these things together and helping get them what they need to build libraries and frameworks. And speaking of things that impact the community and this is something that people are asking about. Since server components are so new, how would you approach hiring and technical screening around them? A lot of folks want to know.

I mean, I don't know that technical screening should be so technology focused, right? Like a developer can learn the technology, so in general I find it's not like the best to quiz you on the most bleeding edge React feature and use that as a basis for hiring. I don't know what? Honestly, someone with no React experience at all is probably going to be a better service components developer than someone who has like ten years building and create React app. Hiring for technology people has never been just about how many years of experience do you have with technology X. To us, when I was hiring a lot at GitHub, it was really about finding people that were motivated.

I mean, for us, the thing that we really sought were people that had made money on the internet before. Like that was the secret sauce to our hiring, right? Because it meant a person had this more cohesive set of things that they cared about. They cared about product. They cared about customers, customer service, they cared about performance cohesively. To me, that's what you really want in a technical person and years of experience with React server components is not one of those things. A person that understands React server components or understands web architecture in general can get up to speed on those things. You want a well-rounded developer. That's really what you want.

Yeah, in our interviews, we don't interview people to use React. It's all vanilla JavaScript. It's more about just understanding web and the language of web and the architecture versus do you know React? What about server components? It's more just the principle of vanilla JavaScript and being an expert in that space. That's it too. I think if you are a seasoned React developer, there's a lot that you already have in your toolkit to build with server components. All the ideas that we've built with server components are around the same primitives that we've built in React since the beginning, composability, and yeah, there are some new things to learn.

All the ideas that we've built with server components are around the same primitives that we've built in React since the beginning, composability, and yeah, there are some new things to learn. But I think if you hire a seasoned React developer, they're not going to have a hard time picking up server components. Yeah, the real difference is now there's more back-end knowledge expected or being used because we've blended the paths so close together that they're the same thing now. If you're just a React dev that knows how to sling style components or design systems, but you've never dealt with request-response patterns, well, you're going to struggle with it, which is expected. So I feel like it's back-end experience that you need, platform experience with understanding how all of these things work together, what a stream is, and that should be the basis.

We were talking about Ruby on Rails and PHP. Those are parallels too if you're coming from those communities. That's actually a great point because I think of RSCs or server components as trying to eliminate what I consider a false distinction there between... The most successful engineers I've ever seen are ones who when they implement a feature, they do it full stack. They don't just whine at the back-end developer to... Which I don't want to be too mean, but sometimes that's necessary because of the way the organization works. The best engineers are the ones who are empowered or have the ability to, from the back-end to the front-end, implement the entire feature.

The reason this doesn't happen sometimes is there's a technological gap there, but who better to implement the back-end or the front-end of a feature than the person who did the other half of it? That's kind of how the front-end role at Facebook has always worked. It's not like, oh, I only write JavaScript. I'm sorry. I'm not going into that PHP file. That's just not how it really works. with React, you're not only now using this same language and you're also using the same programming model. I'm hoping that we can eliminate a little bit of this false distinction here, which is not to say there aren't a lot of other types of engineers that do stuff on the back-end, but at least when it comes to building the application UI part, I don't think that distinction is that interesting and hopefully this blurs the lines a lot more.

All right. Let's hear from the audience. Clap if you are an aspiring or current full-stack engineer. All right. Yeah. There you go. Okay. Cool. All right. So, you know, you get the griping a little bit. This is kind of a little bit of a griping. More of a criticism, I guess. I don't know.

How do these server components differ from other historical apps that ran UI on the server side? It seems like we're slingshotting back. Wait. I'm sure you've heard this argument before. What do you say? I'll give a visual description for this phenomenon, right? So, we always talk about this in technology that, you know, oh, we reinvented Apache or something, right? Like, we're always reinventing something that we did before.

In part, that's true. Like, we do sometimes oscillate between things like this, especially in the Internet space. There's servers and there's clients. So, you're going to constantly see workloads go back and forth between these two things. The way that I like to visualize it, though, is that in the early days, we were down here, right? We had very basic just server responses, you know, Perl and PHP and stuff. And then we started doing more sophisticated things and we discovered that certain workloads like to really be delivered statically, you know, or dynamically, right?

And then we started doing more sophisticated things and we discovered that certain workloads like to really be delivered statically, you know, or dynamically, right? So, first, we were static and then we went dynamic. And then we're like, oh, but JAMstack will go back and be static again. And now we're talking about, well, let's move workloads back on the server, right? It's not back and forth, though. It's really like a spiral, right? So, it looks like a circle from above, but if you tilt to the side, it's a spiral where we continue to discover and improve the various elements as we go up the spiral of technology. So, we're always becoming more sophisticated, and even though it might feel sometimes like this slingshotting back and forth, I think every time we go back and forth, we discover something new. It is a beautiful metaphor. It really is. Honestly, yeah.

I would also say that, like, if you think about the statement for, like, more than two seconds and just list out all of the capabilities of the technology that we have today and compare it to, like, how you would build a PHP app in, like, 2011, it's not the same. I mean, there's a surface level pattern matching that you can go, oh, it has the same quality that I liked about building apps back in the day. But I think if you went all the way back to just slinging HTML using, like, a fully backend framework, you would very quickly miss the stuff that React gives you. I think we've taken for granted how many interesting problems have been solved over the last ten years even when we've been in this kind of spa overreaction, perhaps.

For example, I always like to describe how a lot of the technological capabilities in React server components and React today, like out of order streaming, you know, resource delivery that streams in, a lot of that stuff is based on things that Facebook built in 2011 in this framework called BigPipe or this, I guess, architecture called BigPipe. It had out of order streaming. It had all of these things that, well, not all of them, but it had a lot of the capabilities that are really mind-blowing and eye-popping about React today. But it didn't have this ability to write the same component on the server and the client. It didn't have this ability to use the same exact programming model. It didn't have the ability to, you know, reconcile and not lose state when you do a page navigation. The high level description of it might have been a little bit similar, but the experience of actually using it was not nearly as nice as writing something in, like, Next.js today.