Server Components are server-only React components that can generate the HTML from an individual component, not necessarily the entire app. Get a brief history and how other frameworks are handling it.
Some of the first great websites like Amazon, eBay and Yahoo used the Perl programming language to generate HTML on the server. Static websites were great, but often data was dynamic and needed to be updated on the fly.
When websites became large enough, text databases were transitioned to mySQL. Data was able to be loaded from the server dynamically. You could update a price, create a new post or add a new product without rebuilding your entire site.
However, it was difficult to connect HTML templating and Perl syntax together for a better developer experience despite templating tools like template toolkit.
PHP made templating easy in the late ’90s and early 2000s. I hated PHP because I felt that HTML should not be mixed with a programming language. This created a lot of potential problems, and was harder to debug. However, PHP’s syntax, speed and popularity were exponentially increased since WordPress adopted it to build a multibillion dollar empire. 70% of server-side websites still use it today.
The idea of Remote Procedure Call (RPC) has existed since the ’70s. It basically servers as a way for a client to communicate with a server as if it were a local function. There are many different forms of this today.
When XML was still popular, people used Simple Object Access Protocol (SOAP) to communicate with their backends.
At some point, programmers realized returning JSON instead of XML is easier and faster, so the REST (Representational State Transfer) protocol became the go-to protocol. It is still used today on Node servers.
It is also worth mentioning GraphQL: while the communicate part works similar to REST, it is more accurately described as a Query Language and API runtime. To me, it is just another protocol.
Before Angular 1 and React, most dynamic websites primarily used the server to generate the HTML. However, the advent of the single-page application (SPA) showed a far better user experience compared to the multi-page application (MPA).
Around that same time, in 2009, Node.js was created along with server-side rendering.
fetch them) so that your client-side package was not extremely large.
Generally speaking, your entire code is run two times (client and server), unless you separate your specific server data into endpoints. This is how Angular with Angular Universal still works today, although I suspect Angular 17 will change this.
A lot of core frameworks do not have a routing system at all. It is the meta-frameworks (Next.js, Nuxt, Remix, SvelteKit, etc.) that have a router. File-based routing allows you to create folders in your dev environment that correspond to specific routes in your application. A small number of people are against it, but I find it incredibly useful.
File-based routing is important because modern frameworks allow you to have a different route for server and client components. This means you can create a server route that loads the data, then injects that into an HTML page on the client.
getServerSideProps, or you could emulate this in Angular with
resolvers. So you will have one file that loads the data on the server, and another file that puts the data into the HTML file. It is important to note that the actual HTML is rendered on the server, and the data is hydrated on the client. File-based routing just makes this easier.
React Server Components do just that. They are server-only React components that can generate the HTML from an individual component, not necessarily the entire app, by returning
jsx. You can have server components inside client components and vice versa. Logically this makes sense, but in practice you have to think about the mental model.
All components are server components by default, unless you use
'use client' in that part of your function. You really won’t even use RSC unless you have a meta framework that handles both server and client rendering well. As of today, Next.js is the adopter.
Imagine your app is one giant server component. You use JSX (or TSX if you’re smart) to create and build HTML. This is basically just using your Node.js server to generate HTML for you. Sound familiar? RSC is just PHP???
Not exactly, but yes. If you generate HTML on the server and display it on the client, it is not reactive in server components, nor in PHP. That means you cannot use
useEffect or any other state management package to dynamically change your data after it is loaded.
script tags for us, and the data into the html page as JSON. But not everything is interactive.
In React, you have your React Component Tree that is loaded to the browser. This means everything can basically be interactive by default. According to Dan Abramov, React’s lead team member, you’re really just adding the ability to create a server tree on the server side different from the client tree. You don’t need access to the server tree on the client as it is not interactive. He goes into detail on the basic understanding in RSC From Scratch.
Svelte’s creator is against Server Components, although I only partly agree with him.
Harris’ main argument is that when you have an unstable connection, like when you’re on a subway, the user experience will not be as good when using something like Server Components. You don’t want to redownload your app just to have interactivity like in the PHP days.
I think he is missing the point here. If you design your app so that the interactive parts do not have to be redownloaded, this won’t matter. You could also poorly design a SvelteKit app to lazy load the wrong items causing the same problems. RSC just gives you more control.
Are we over-correcting? I emphatically say no.
Source maps help with debugging in production environments by mapping your compiled code to the original code. Basically, there will be no source maps with RSC, making debugging that part of the app impossible. Ironically he used the Source Map example again to illustrate how leaking server only code to the client can be a problem. Do we want server source maps or don’t we, Rich!?
While I think this is a valid point, I think it is rare that you can’t get the important parts of debugging done in a developer environment. However, I am not creating a framework, so I really can’t argue against this.
Jack Herrington claims the old method of generating server components, using the App Directory, is faster. Other people have run his test with similar results:
However, as Theo points out, these tests are done on a local machine. This means you don’t get the speed performance that CDN and caching will give you.
Your local machine is not the same thing as a fast server environment. It is actually quite nuanced on whether or not you should use server components. Some situations will be faster without them.
However, even Herrington thinks the speed of RSC will improve over time, hopefully to be faster than the old Next.js App Directory in all cases. TBD.
Nuxt has implemented their own version of Server Components from Vue.
This seems to be in a slower development state than RSC, but the future will tell.
It is also worth nothing that you may see colocation in some frameworks, which is backend code in frontend files. The code is written in a way to make it look as if you’re calling a server function in the client, when in reality it creates an endpoint. The norm seems to be using
server$() to create them.
He mentions the security problem can be solved with CSRF protection and CSP primitives just like SvelteKit uses, so why not just get the other frameworks to add that as well (except when they want open endpoints).
I don’t use React. I have built some complex apps myself to learn it, but ultimately it is not for me. However, I think Server Components are a good thing. Let’s just keep HTML that is non-interactive, loading once.
I think the Source Map issue will figure itself out over time, and I believe the latency issue is more of a design problem. You have to know when to use them.
I also think the colocation is a great idea because it makes the developer experience better. I personally do use SvelteKit, even though I don’t agree with everything Rich Harris says. The developer experience and user experience seem to be a winner in most cases.
Server Components are just another way to optimize your code in React, or any other framework like Nuxt. It is not as complicated as it seems, but it is also not PHP.
I love the idea, and I am ready for other frameworks to see its potential.
Jonathan Gamble has been an avid web programmer for more than 20 years. He has been building web applications as a hobby since he was 16 years old, and he received a post-bachelor’s in Computer Science from Oregon State. His real passions are language learning and playing rock piano, but he never gets away from coding. Read more from him at https://code.build/.
Subscribe to be the first to get our expert-written articles and tutorials for developers!
All fields are required