Frontend Schism: Will React Server Components Destroy React?
“One thing that is clear to me is that React Server Components will destroy React,” said Igor Minar, one of the creators of the Angular framework and now senior director of engineering at Cloudflare. Others, notably frontend cloud company Vercel, think that React Server Components “augment the fundamentals of React.” So who’s right?
To quickly summarize, React Server Components (RSCs) are components that run exclusively on the server. As the React team explained in March 2022, when stable support for this “new type of component” was added in React 18, RSCs “run ahead of time and are excluded from your [client-side] JavaScript bundle.” Next.js (developed by Vercel, which also supports and helps fund React development) was the first major framework to announce support for RSCs, in Next.js 13 released in October 2022. This version of Next.js integrated RSCs as part of its new App Router architecture.
The Pros and Cons of RSC
For Next.js users, RSCs can be useful. YouTuber Theo Browne recently did a presentation at React Summit 2024 and sang the praises of RSC, which the dev tools company he runs has been using for over a year now.
“I couldn’t recommend Server Components highly enough.”
– Theo Browne, YouTuber and CEO Ping Labs
“If you want to learn something new and aren’t scared of it possibly not being the next big thing, I couldn’t recommend Server Components highly enough,” Browne concluded. “Like honestly, I’d be really surprised if these [RSC] aren’t how we end up writing software, going forward.” (It’s worth noting: up until earlier this month, Vercel was a sponsor of Browne’s popular YouTube show — a relationship he has always been upfront about.)
Others, however, have found the RSC adjustment more challenging. “The mental overhead of a mixed client/server graph has been my biggest reservation about RSC since it was announced,” said Vue.js creator Evan You on X back in June.
There are other adoption challenges for RSC. One of the aspects that make adoption difficult is that applications migrating to this model require supporting infrastructure and — depending on the flavor of React — extended configuration and additional middleware integration that is potentially incompatible with the current application deployment and hosting model that a client-side app may be built on top of.
RSC technology “creates a delayed ambush-by-JS effect.”
– Alex Russell, Partner Product Manager on Microsoft Edge
Although popular with some Next.js users, RSCs have been controversial in the rest of the web development community. At the same time I spoke to Minar, I was also trying to set up a time to talk with Microsoft’s Alex Russell about his “HTML-first” philosophy. Russell has been a long-time critic of React, so I asked him about his thoughts on RSC specifically. He emailed back this explanation of why he dislikes them:
“RSC’s raison d’etre [reason for being] is to reduce the amount of code that’s necessary to send to the browser up-front because that code is often the source of poor Core Web Vitals outcomes. It does this by running component sub-trees within React Applications on the server up to the point where a developer includes a ‘use client’ directive. At that point, the server sort of nopes out and defines everything in the tree underneath that component as “client-side”, meaning that the server has to then send down all the code that defines every component in the sub-tree, along with any dependencies. This creates a delayed ambush-by-JS effect.”
Even with App Router, Next.js performs poorly in Core Web Vitals compared to its competition; HTTP Archive Core Web Vitals Technology Report
But again, some developers think RSCs are a useful evolution. In an April post here on The New Stack, Paul Scanlon wrote that RSCs make “data easily accessible from within a component.” He argued that RSCs “help with understanding what an application is doing because the logic, data, and the resulting user interface elements are neatly co-located in the same file, and when compared to chasing down props and attempting to follow the data journey, the developer experience is often better.”
Better data fetching is one feature of RSCs that Igor Minar likes. “This improved component encapsulation, that in RSCs includes data fetching, is one positive property of RSCs (maybe the only one?) that I do bring up with developers,” he said. “We should try to preserve this feature and make it the norm in the broader web development ecosystem, but without all the downsides that come with RSCs.”
How It Started
It’s worthwhile revisiting the reason why RSCs were invented by the React team. They were first introduced by the React project way back in December 2020, as a proposed data fetching solution for React. The idea was to move relevant React components away from the client and into the server.
“React could and did execute on the server side before, albeit very inefficiently,” Minar noted. “The change with RSCs is that some components execute exclusively on the server side. And that’s new. With RSCs you must run (a portion) of your React application on the server side, while before RSCs, you could run React on the server as an optional optimization, but you were able to opt out of that (and most of the React ecosystem did).”
As React engineer Dan Abramov explained in a December 2020 video, “These are regular React components still, but we’re going to call them Server Components because they execute on the server and on the server only — they’re never shipped to the client.”