The React paradigm shift

React is currently in a transition period, moving away from a 100% client-side approach toward one where the server plays a significant role in rendering interfaces.

Why? Let’s take a closer look at the main symptoms reflecting this transformation.

The arrival of Server Components

Still described as experimental at the time this article is being written, this topic seems to strongly influence the roadmap and the content of the releases.

Here are the motivations behind this feature as outlined in the specification:

Server Components address a number of challenges in React that we’ve seen across a wide range of apps. Initially we searched for targeted solutions to these problems as this can often lead to a simpler solution. However we weren’t satisfied with the approaches this led us to. The fundamental challenge was that React apps were client-centric and weren’t taking sufficient advantage of the server. If we could allow developers to easily leverage their server more, we could solve all of these challenges and provide a more powerful approach to building apps, small or large.

These challenges fall into two main buckets. First, we wanted to make it easier for developers to fall into the “pit of success” and achieve good performance by default. Second, we wanted to make it easier to fetch data in React apps.

(Note : see source.)

Digging deeper into the specification, another important point becomes clear: Server Components are seen as a complementary API to SSR (Server-Side Rendering) frameworks. The React team is collaborating with these frameworks and relies on them to enable easy adoption of this new feature :

(...), using Server Components will require integration with an application’s routing system and bundler. To help the community understand how this can work we will initially focus on adding support for Server Components into one or more frameworks. This will make it easy for developers to quickly try out Server Components. It will also serve as a guide for how library authors can add support for Server Components in their libraries and how individual app developers can add support in their apps.

This likely explains the two points that follow.

The neglection of Create React App

Formerly the preferred tool for starting a React SPA (Single-Page Application), it is now considered deprecated by the community, although this was never officially stated.

Here is an excerpt from a tweet by Dan Abramov (a prominent developer at Meta) that gives some context on the disinterest of its creators:

when i was thinking about possible futures for Create React App, it was clear client-only doesn’t make sense. way too limiting.

why are we always producing an empty HTML file if React can pre-render to HTML? why can’t i make a blog by map()ing over markdown files on my disk?

[...]

here’s the thing.

the current crop of modern frameworks (specifically, Next.js and Gatsby) already work this way.

they let you start 100% static + client. HTML generation, file-based routing, SPA navigations, and real client code (as much as you like). that’s the baseline.

however, if you do want to use the server for some dynamic route — like, reading from a DB instead of a file — they let you do that easily. you just change a couple of lines of code. your existing pages remain static/client.

frameworks provide LESS LOCK-IN in that sense.

so i realized that building this would just building a more limited version of what Next.js/Gatsby already have to offer. it would do exactly the same things they already do, but would not allow you to do more.

modern frameworks are hybrid. they let you build SPAs and more.

[...]

(Note : see source.)

The new recommendations of the doc

The React documentation now presents SSR frameworks as the default solution for starting a new React application.

You can definitely use React without a framework—that’s how you’d use React for a part of your page. However, if you’re building a new app or a site fully with React, we recommend using a framework.

Here’s why.

Even if you don’t need routing or data fetching at first, you’ll likely want to add some libraries for them. As your JavaScript bundle grows with every new feature, you might have to figure out how to split code for every route individually. As your data fetching needs get more complex, you are likely to encounter server-client network waterfalls that make your app feel very slow. As your audience includes more users with poor network conditions and low-end devices, you might need to generate HTML from your components to display content early—either on the server, or during the build time. Changing your setup to run some of your code on the server or during the build can be very tricky.

[…]

(Note : see source.)

It’s pretty clear: the team behind React no longer considers SPA as a viable paradigm for most web applications.

By relying on the benefits provided by frameworks, the React team wants to put forward a new, more server-oriented approach.

Do SPAs belong to the past?

This policy change doesn’t really impact the validity of the approach. Frontend web development has been largely built around SPA libraries for years, and while the SSR approach addresses some of their issues, it’s nothing new.

SSR frameworks and Server Components add another layer of complexity to tools that are already criticized for their complexity, justifying the emergence of other, simpler libraries like Svelte or htmx.

No doubt, these are beneficial solutions for many applications.
But not for all! If you don’t need SEO, and neither the size of your bundle nor the optimization of data retrieval are major concerns, you probably don’t need them. Choose the tools that are right for you.