← Blog

React innovates, again

#Reactjs #web

“[T]he modern web UI development, which React pioneered and led ever since, has reached a point of maturity. […] In other words, in my view, Vue 3 marks no Next Big Thing in sight and a shift of focus to incremental improvement: smaller bundle size, performance optimization, more intuitive API, better tooling, etc.”

That’s a quote from my earlier post “What does Vue 3 mean”. Well, I spoke too soon.

Again,1 it’s React that seeks to push the boundary of the modern frontend web development with its recent annoucement on “React Server Components”, accompanied by a recorded talk, an RFC, and a demo app. Accoring to the RFC, React Server Components, sometimes abbreviated to RSCs, are an upcoming feature currently under development that will “allow developers to build apps that span the server and client, combining the rich interactivity of client-side apps with the improved performance of traditional server rendering.”

The announcement has generated a lot of excitement and discussion in the community. As a way to solidify my understanding, I, too, would like to jot down my early impressions on React Server Components after skimming through the original materials from the React team as well as the community discussions. Here I’ll have to focus on the user/developer experiences rather than implementation details.

No free lunch

Most decisions in software, just as in life, involve making trade-offs. And React Server Components are no exception. The real question, then, is whether the benefits are worth the costs.

The main benefit of Server Components is what the React team dubbed “Zero-Bundle-Size”, or not having to ship code running only on the server. As pointed out in the announcement talk, this can be particularly significant with non-application code, i.e. dependencies. A huge win for end users. As Shawn “swyx” Wang noted in his recent blog post on React Server Components, this approach leads to what Dan Abramov of the React team called “disappearing application” (as opposed to Svelte’s original tagline, “disappearing framework”).

In a sense, this and most other expected benefits of React Server Components all stem from the common basis—that React is going, though only selectively, server-side.

On the other hand, the main cost is even more complex mental model for developing React applications. While React was originally touted for its minimal API surface area (“It’s just JavaScript!” or see this talk in 2014 by Sebastian Markbåge of the React team), its abstraction grew in complexity over time. In fact, whenever the React team ventured to introduce big changes, most notably Hooks and Concurrent Mode, “thinking in React” became a bit more convoluted and, to some, even frustrating.2 At least the core domain of writing React applications thus far remained on the client side. With Server Components, that’s no longer the case.

In addition to the extra cognitive burden, choosing to adopt React Server Components will necessarily lead to all the nuisance of having to provision a server.3

No more second-guessing

Maybe I’m plain wrong here, but I get a sense that React Server Components are the React team’s response to what Tom MacWright raised in his viral blog post earlier this year, “Second-guessing the modern web.” As it’s URL (/spa-fagitue) suggests, the post is about how React-style SPAs are ill-equipped for certain use cases with little-to-no interactivity and how the existing solutions/workarounds fall short.

This is not to say that the React team are responding directly to MacWright.4 In fact, while his post offers a good summary/survey of this topic, MacWright is not the first person to raise the point. In some sense, the very existence of React metaframeworks—such as Next.js (v1 release in October 2016), Gatsby (v1 release in July 2017) and more recently Remix (currently in “Supporter Preview”)—is a testament to the limitations of client-side React SPAs.

From this vantage point, React Server Components may be considered a key piece in finally solving “the modern web” and its discontents, most of which arise from the fact that React applications fundamentally live in the browser, by allowing these applications to directly leverage the server. A large JavaScript bundle? Don’t ship the code (“zero-bundle”)! Bad performance from sequentially fetching data from the server? Remove the round trips from client to server! Risk of exposing sensitive user data? Keep them in server! And so on and so on.

What’s next

React Server Components are still very much a work in progress, with no promise on its release date. Considering that the Concurrent Mode still remains experimental, we may not see Server Components in production for a while.5

That said, it is telling that the React team is collaborating with the Next.js team in the development of React Server Components. Making Server Components available through a popular and well established metaframework is likely the path of least resistance for adoption where developers can benefit from using Server Components without having to face all their quirks. Besides, the door will always remain open for those who would like to get their hands on Server Components.

And, of course, the announcement of React Server Components has gotten other frontend framework communities, as well as the broader web development community, talking.6 Not everyone seems convinced (nor should they be), but I expect the conversation to continue as React Server Components introduce a truly novel approach to addressing a real problem shared by most SPA frameworks.

Footnotes

  1. It’s almost admirable how the React team does not shy away from rocking the boat and upset the status quo that it often led to establish, from the very first introduction of React, to Hooks, to Concurrent Mode (still flagged as experimental), and now to React Server Components. ↩

  2. Here’s a blog post expressing the said frustration by Jared Palmer, an author of a popular React form library called Formik. Apparently, this very frustration convinced some developers to become Svelte converts. ↩

  3. Apparently, React Server Components is also set to go “serverless”. But replacing traditional servers with “serverless” functions come with their own costs. ↩

  4. Or, are they? 👀 ↩

  5. Hopefully, there’s some indication that we won’t have to wait as long. ↩

  6. Here’s one such discussion from the Vue community. ↩