DEV Community

Cover image for React Server Components: Community Debates and Divergences
Leapcell
Leapcell

Posted on

React Server Components: Community Debates and Divergences

Image description

Leapcell: The Best Serverless Platform for Nodejs Hosting

Introduction to React Server Components

Previously, when a user accessed a React application, the server would return an empty HTML file containing one or more JavaScript files. The browser would parse the HTML, then download the JavaScript files and render the web page on the client - side.

The emergence of React Server Components (RSC) has expanded the scope of React. As the name implies, React Server Components are React's server - side components. They only run on the server and can call server - side methods, access databases, etc. After each pre - rendering, RSC sends the HTML to the client, which then hydrates and formally renders it. The advantage of this approach is that some of the code that was originally packaged in the client - side JavaScript file can now run on the server, thus reducing the client - side burden and improving the overall performance and response speed of the application.

"Making full use of server resources" is the biggest motivation for the release of RSC. In other words, everything that does not require interaction should be placed on the server. The React official provided a very typical example - rendering markdown content.

Client - side Component Rendering

import marked from'marked'; // 35.9K (11.2K gzipped)
import sanitizeHtml from'sanitize-html'; // 206K (63.3K gzipped)

function NoteWithMarkdown({text}) {
  const html = sanitizeHtml(marked(text));
  return (/* rendering */);
}
Enter fullscreen mode Exit fullscreen mode

In this example, if rendered with client - side components, the client needs to download at least over 200k of files to render the content. However, the markdown content here actually does not require interaction and will not generate a need for updated information due to user operations, which is very much in line with the concept of using RSC. If using RSC:

Server - side Component Rendering

import marked from'marked'; // zero packaging size
import sanitizeHtml from'sanitize-html'; // zero packaging size

function NoteWithMarkdown({text}) {
  // the same as before
}
Enter fullscreen mode Exit fullscreen mode

The dependency packages are placed on the server, and the server only returns the content that the user needs to see. The client - side package is suddenly reduced by over 200k.

Up to this point, the mainstream view in the community was positive until Next.js, based on the characteristics of RSC, advanced aggressively, and then differences emerged.

Community Disagreements

The most fundamental reason for the disagreement is that React introduced the concept of the server - side. Server - side components and client - side components have obvious differences:

  • Server - side components cannot use React hooks like useState and useEffect; client - side components can.
  • Server - side components have no access to browser APIs; client - side components have full browser API permissions.
  • The server - side has the right to directly access server - side programs and APIs; while client - side components can only access some programs through requests.

With the release of Next.js v13 and v14, RSC, which is still in the canary version in React, was moved to the production environment by Next.js. 'use client' and 'use server' are being discussed by more and more people. Developers say there are now "two Reacts", and the community has started arguing about whether React has progressed or regressed over the years.

Image description

Opposing Voices in the Community

Renowned Software Engineer Cassidy Williams

She pointed out the development problems of React in the past two years:

  • The new concepts brought by "two Reacts" are not clear and easy - to - understand knowledge for most people. This split may lead to additional confusion and learning barriers.
  • Since June 2022, React has not only had no new releases but also encouraged developers to use upper - layer frameworks. These upper - layer frameworks released features based on RSC without waiting for RSC to be upgraded to a stable version (almost naming Next.js).
  • In recent years, some members of React have joined the teams of other upper - layer frameworks. They have not only neglected to update the version but also neglected to update the documentation.

Tanner Linsley, the Developer of React Query

He also expressed concerns and dissatisfaction with the development of React:

  • Since React introduced hooks and the suspense API, React has overly focused on a few concepts. Although these new concepts technically push the limits and boundaries of the single - thread UI API, they have little impact on his daily work of providing value to users.
  • Judging from the release of RSC, the React team no longer has such a strong pursuit of client - side performance.

Tom MacWright, an Expert in Map Technology and Visualization Technology

He criticized the fragmentation of the React ecosystem:

  • Currently, React updates slowly. Instead, two upper - layer frameworks, Remix (funded by Shopify) and Next.js (funded by Vercel), are in fierce competition.
  • The intersection between the React team and the Next.js team is too large, giving Vercel a leading advantage. Other frameworks that do not belong to the Vercel and Facebook ecosystems, such as Remix, will be affected by bugs in React that have been fixed but not released.

Positive Attitudes in the Community

Facing the increasing number of opposing voices in the community, Dan Abramov, a major contributor to React, also expressed his views several times. He has an open attitude towards technological changes:

  • The App Router of Next.js has great ambitions, but it is still in the initial stage of development and will be iterated to be more excellent in the future.
  • The work of client - side components is UI = f(state), and the work of server - side components is UI = f(data). React hopes to combine the advantages of both to achieve UI = f(data, state). He called on the community to jointly promote the realization of this goal.
  • Regarding Next.js releasing RSC to the production version, Dan believes that "production - ready" is a subjective judgment. Although RSC is still in the canary version, Facebook has already used it extensively. He believes that verification in practice can improve the technology more quickly and ultimately achieve maturity and stability.
  • The development of new technologies is a gradual process involving continuous testing, feedback, and iteration. The power of the community is very important.

Overall, Dan hopes that everyone can put aside their prejudices and jointly explore the next - stage transformation of React in practice.

In Conclusion

RSC definitely has a positive significance in enhancing modern web application development. The most obvious advantages are that it can improve the performance of large - scale applications, reduce client - side load, optimize the data acquisition process, etc. Completing these tasks through RSC is more convenient than the previous SSR solutions.

With the release of Node v20 and the application of RSC, the distance between the front - end and the server - side is further reduced. We have the opportunity to witness the "backendization" of front - end work - front - end engineers will handle more work that traditionally belongs to the back - end, such as data query optimization, server resource management, etc. This actually opens a door for front - end engineers, giving us the opportunity to comprehensively master the entire web.

Leapcell: The Best Serverless Platform for Nodejs Hosting

Image description

Finally, I recommend a platform that is most suitable for deploying Node.js services: Leapcell

1. Multi - Language Support

  • Develop with JavaScript, Python, Go, or Rust.

2. Deploy unlimited projects for free

  • pay only for usage — no requests, no charges.

3. Unbeatable Cost Efficiency

  • Pay - as - you - go with no idle charges.
  • Example: $25 supports 6.94M requests at a 60ms average response time.

4. Streamlined Developer Experience

  • Intuitive UI for effortless setup.
  • Fully automated CI/CD pipelines and GitOps integration.
  • Real - time metrics and logging for actionable insights.

5. Effortless Scalability and High Performance

  • Auto - scaling to handle high concurrency with ease.
  • Zero operational overhead — just focus on building.

Image description

Explore more in the documentation!

Leapcell Twitter: https://x.com/LeapcellHQ

Top comments (0)