React Server Components Panel Discussion

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Watch video on a separate page

FAQ

RRSE stands for React Server Components and it is recommended for all React developers to learn it as it allows the use of server components on the server, enhancing application performance, especially for data-intensive applications.

Yes, existing React applications can benefit from RRSE by improving performance in server-side data handling. However, there's no immediate urgency to convert existing applications unless there are specific use cases that require it.

RSCs offer the flexibility to combine the best aspects of single-page and multi-page applications, simplifying the development process by enabling server-side rendering and reducing client-side complexity.

While not mandatory, starting a new application with RSCs can future-proof the project by leveraging server-side capabilities without needing a significant rewrite later on.

Server actions complement RSCs by handling mutations and server-side data fetching, simplifying the process of building full-stack applications without needing extensive API endpoints.

Partial pre-rendering is an experimental feature that combines the benefits of caching and streaming by pre-rendering cacheable components and streaming dynamic parts, enhancing performance.

RSCs allow for more granular control by enabling server-side rendering at the component level, unlike traditional methods which typically operate at a higher level of abstraction.

Yes, RSCs can simplify the development of internal corporate apps by reducing complexity and improving data handling, particularly in scenarios involving large data sets or server-side operations.

Yes, RSCs can be incorporated into other frameworks like Redwood.js, and efforts are underway to expand support across various frameworks beyond Next.js.

Companies should focus on hiring developers with a strong understanding of web architecture and backend experience, rather than specific RSC expertise, as the technology is new and evolving.

Tom Preston-Werner
Tom Preston-Werner
Ben Holmes
Ben Holmes
Kathryn Middleton
Kathryn Middleton
Matt Carroll
Matt Carroll
Josh Comeau
Josh Comeau
Andrew Clark
Andrew Clark
33 min
13 Nov, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Panel discussion on React Server components, including benefits, considerations, and importance for React developers. Emphasis on leveraging server components in new applications and existing frameworks. Exploration of server actions, partial pre-rendering, simplification of data fetching with RSE, challenges, limitations, and harmonizing client-server architectures with React Server Components. Integration of client and server actions, addressing tool complexity, challenges in server component adoption, hiring mindset, full-stack development, technology advancements, and the evolution of technology capabilities.

1. Panel Discussion on RRSE

Short description:

Panel discussion on React Server components and the importance of learning RRSE for React developers. Benefits of using server components and considerations for existing applications.

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.

2. Leveraging React Server Components

Short description:

The importance of learning React server components, benefits of incorporating server components in new applications, and considerations for leveraging server components in existing frameworks.

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.

QnA

Server Actions and Partial Pre-rendering

Short description:

Discussion on the necessity and benefits of server actions for mutations in React, the evolving nature of server components, and the potential of partial pre-rendering for caching and dynamic content streaming.

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.

Simplification with React Server Components

Short description:

Discussion on the simplification of server-side rendering with React Server Components, the excitement around partial prerendering for dynamic data, and the potential benefits of RSEs for corporate applications.

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.

Data Fetching Simplification with RSE

Short description:

Exploring the simplification of data fetching with React server components for a more straightforward development approach in specific project contexts.

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.

Challenges and Limitations of Server Components

Short description:

Exploring reasons for potential limitations in adopting React server components due to server-side JavaScript constraints, native framework support, and idealized versus current implementation challenges.

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.

Harmonizing Client and Server-side Architectures

Short description:

Exploring the flexibility and similarities between client-side and server-side architectures with React Server Components, emphasizing the opt-in nature of RSEs and the seamless integration of existing React code structures with server-side roots.

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.

Integrating Client and Server Actions

Short description:

Exploring the seamless integration of client and server actions, emphasizing the benefits of combining different primitives for enhanced functionality. Addressing the challenges of making RSCs independent of Next.js by defining boundaries and enhancing documentation to foster community understanding and collaboration. Enabling adoption of server components in corporate environments like Meta and Microsoft, emphasizing the need for sophisticated bundlers and infrastructure to support technology integration.

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.

Addressing Tool Complexity in Adoption

Short description:

Discussing the importance of having tools that solve specific problems and the community collaboration in applying them. Examining the challenges faced by companies like Meta and Microsoft in adopting server components due to complex infrastructure. Highlighting the need for engineering work and sophisticated bundlers to enable organizations to adopt new technologies.

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.

Challenges in Server Component Adoption

Short description:

Discussing the challenges of adopting server components on a larger scale, the need for fundamental changes in bundlers to support server components, and the goal to make technology adoption easier for organizations. Emphasizing the complexity of building server components and recommending against most people attempting to create their own implementations. Focusing on connecting individuals working on building libraries and frameworks and addressing inquiries about hiring and technical screening for server components.

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.

Technical Screening and Hiring Mindset

Short description:

Discussing the importance of hiring motivated individuals over technology experts, emphasizing the value of well-rounded developers with diverse skills and experiences. Highlighting the shift towards hiring based on broader capabilities and mindset rather than specific technology expertise.

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.

Integrating Full-Stack Development

Short description:

Discussing the importance of full-stack engineers and the integration of back-end and front-end development. Emphasizing the need for a well-rounded skill set and the elimination of false distinctions in development roles.

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.

Technology Advancements and Paradigm Shifts

Short description:

Exploring the shift between server-side and client-side development paradigms and the cyclical nature of technology advancements.

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?

The Evolution of Technology Capabilities

Short description:

Highlighting the evolving nature of technology, from static to dynamic approaches, with continuous improvements and discoveries. Comparison of past and present tech capabilities, emphasizing the advancements made in solving complex problems. Illustrating the foundation of React's capabilities based on earlier frameworks like BigPipe, showcasing the evolution towards more efficient and user-friendly development experiences.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Simplifying Server Components
React Advanced 2023React Advanced 2023
27 min
Simplifying Server Components
Top Content
Watch video: Simplifying Server Components
React server components simplify server-side rendering and provide a mental model of components as pure functions. Using React as a library for server components allows for building a basic RSC server and connecting it to an SSR server. RSC responses are serialized virtual DOM that offload code from the client and handle interactivity. The client manifest maps serialized placeholders to real components on the client, enabling dynamic rendering. Server components combine the best of classic web development and progressive enhancement, offering the advantage of moving logic from the client to the server.
A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.