Introduction
So, here’s something that makes me feel old: React celebrated its 10th birthday this year!
In the decade since React was first introduced to a bewildered dev community, it’s gone through several evolutions. The React team has not been shy when it comes to radical changes: if they discover a better solution to a problem, they’ll run with it.
A couple of months ago, the React team unveiled React Server Components, the latest paradigm shift. For the first time ever, React components can run exclusively on the server.
There’s been so much friggin’ confusion about this online. Lots of folks have lots of questions around what this is, how it works, what the benefits are, and how it fits together with things like Server Side Rendering.
I’ve been doing a lot of experimentation with React Server Components, and I’ve answered a lot of my own questions. I have to admit, I’m way more excited about this stuff than I expected to be. It’s really cool!
So, my goal today is to help demystify this stuff for you, to answer a lot of the questions you might have about React Server Components!
To put React Server Components in context, it’s helpful to understand how Server Side Rendering (SSR) works. If you’re already familiar with SSR, feel free to skip to the next heading!
Originally, React was designed to work exclusively in-browser, on the user’s device. The user would receive an HTML file that looked like this:
That bundle.js script includes everything we need to mount and run the application, including React, other third-party dependencies, and all of the code we’ve written.
Once the JS has been downloaded and parsed, React springs into action, conjuring all of the DOM nodes for our entire application, and housing it in that empty
The problem with this approach is that it takes time to do all of that work. And while it’s all happening, the user is staring at a blank white screen. This problem tends to get worse over time: every new feature we ship adds more kilobytes to our JavaScript bundle, prolonging the amount of time that the user has to sit and wait.
Server Side Rendering was designed to improve this experience. Instead of sending an empty HTML file, the server will render our application to generate the actual HTML. The user receives a fully-formed HTML document.
That HTML file will still include the
