The direction of this work is exciting, and while it isn’t yet production ready, is worth keeping on your radar. The following resources may be of interest:
- The RFC is worth reading as is Dan and Lauren’s talk worth watching.
- React 18 status for Next.js and the Server Components roadmap for Next.js
- React 18 beta status
- Shopify Hydrogen and Server Components
Server-side rendering limitations
With React Server Components, our components can be refetched regularly. An application with components which rerender when there is new data can be run on the server, limiting how much code needs to be sent to the client.
[RFC]: Developers constantly have to make choices about using third-party packages. Using a package to render some markdown or format a date is convenient for us as developers, but it increases code size and hurts performance for our users
Server Components are not a replacement for SSR. When paired together, they support quickly rendering in an intermediate format, then having Server-side rendering infrastructure rendering this into HTML enabling early paints to still be fast. We SSR the Client components which the Server components emit, similar to how SSR is used with other data-fetching mechanisms.
[RFC]: If we migrate the above example to a Server Component we can use the exact same code for our feature but avoid sending it to the client - a code savings of over 240K (uncompressed):
It’s been considered a best-practice to only serve code users need as they need it by using code-splitting. This allows you to break your app down into smaller bundles requiring less code to be sent to the client. Prior to Server Components, one would manually use
React.lazy() to define “split-points” or rely on a heuristic set by a meta-framework, such as routes/pages to create new chunks.
Some of the challenges with code-splitting are:
- Outside of a meta-framework (like Next.js), you often have to tackle this optimization manually, replacing
importstatements with dynamic imports.
- It might delay when the application begins loading the component impacting the user-experience.
Server Components introduce automatic code-splitting treating all normal imports in Client components as possible code-split points. They also allow developers to select which component to use much earlier (on the server), allowing the client to fetch it earlier in the rendering process.
Will Server Components replace Next.js SSR?
No. They are quite different. Initial adoption of Server Components will actually be experimented with via meta-frameworks such as Next.js as research and experimentation continue.
To summarize a good explanation of the differences between Next.js SSR and Server Components from Dan Abramov:
- Server components enable access to the back-end from anywhere in the tree. When using Next.js, you’re used to accessing the back-end via getServerProps() which has the limitation of only working at the top-level page. Random npm components are unable to do this.
- Server Components may be refetched while maintaining Client-side state inside of the tree. This is because the main transport mechanism is much richer than just HTML, allowing the refetching of a server-rendered part (e.g such as a search result list) without blowing away state inside (e.g search input text, focus, text selection)
Some of the early integration work for Server Components will be done via a webpack plugin which:
- Locates all Client components
- Creates a mapping between IDs => chunk URLs
- A Node.js loader replaces imports to Client components with references to this map.
- Some of this work will require deeper integrations (e.g with pieces such as Routing) which is why getting this to work with a framework like Next.js will be valuable.
As Dan notes, one of the goals of this work is to enable meta-frameworks to get much better.
Learn more and share feedback with the React team
To learn more about this work, watch the talk from Dan and Lauren, read the RFC and do check out the Server Components demo to play around with this work. With thanks to Sebastian Markbåge, Lauren Tan, Joseph Savona and Dan Abramov for their work on Server Components.
Interesting relevant threads: