In December 2020, the React team introduced an experimental feature called React Server Components. This may leave you wondering how exactly these "server components" differ from Server Side Rendering (SSR).
If you enjoy this post, please give it a 💓, 🦄, or 🔖 and consider signing up for 📬 my free weekly dev newsletter
SSR Is All About the Initial Page Load
When you're using SSR, you are sending HTML to the client and then loading up all your typical React JavaScript. The application is considered hydrated once the JavaScript is loaded and the app is back to being a functional client-side React app. This means that, after the initial page load, your app is essentially the same old React app that you'd have if you weren't using SSR. In SSR, all of your components are still client components outside of the fact that your first page load was pure HTML!
TL;DR: SSR is basically all about that initial load seeming more like a traditional server-rendered app.
React Server Components Are Always Rendered on the Server
React Server Components are always rendered on the server. These are likely components that are fetching some data from your backend, so it makes sense to have the rendering of these components colocated with the data that's being fetched. Whenever these components need to be rerendered, they are refetched from the server and merged into the existing, client-side React component tree. What's cool about this is client state is preserved even though we're refetching parts of the view from the server.
React Server Components Are More Likely to Reduce Bundle Size
Since SSR apps are about the initial page load, the client is likely to end up downloading all your dependencies as they explore your application (after all, it's a client side app after that first page load). However, if you have dependencies for a React Server Component, those dependencies will always be only on the server since those React Server Components are not shipped to the front-end until they have been rendered.
Conclusion
While React Server Components and SSR both involve some React rendering on the server, they're actually quite different! RSCs are a very interesting development and I certainly look forward to learning more about them.
Top comments (4)
From a high level view how does this differentiate from Blazor Server?
While I understand that Blazor runs on top of dotnet runtime on top of wasm (perf penalties) is it possible that RSC can also have some diffing mechanisms similar to Blazor Server? It would be interesting to know efficiency comparisons from an architectural perspective.
At the moment, the most clear and concise explanation.
Thanks for this.
Thank you!!
Gotta, its all about the things happen before the initial page load, then its deep architectural level thing