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 */);
}
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
}
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.
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
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.
Explore more in the documentation!
Leapcell Twitter: https://x.com/LeapcellHQ
Top comments (13)
It’s 2025. Why are we still talking about react? The slowest most memory heavy framework with a bunch of nonsense patches like useMemo and useCallback… Even the last sliver of hope was lost with the failure of the so called react forget (compiler). It was a good run, but it’s time to let it rest in peace. Server components were introduced to support Vercel’s business model. No one asked for it nor needs it. End of story.
Actually server rendering was requested by the community and that opened up a big can of worms. Now we're rendering on the server, but we cannot access the data on the server directly... All of this is community driven. There's just the SPA part of the community that doesn't care about server side rendering or RSC. They will either change their mind to join the future or move to some framework that tries to stick to the past.
Since when is server side rendering an issue? There are literally 1000s of mature frameworks and solutions and template engines that are designed to do exactly that. Ignoring Next.js what problem does RSC solves that hasn't been solved 20+ years ago? I personally have no respect for Vercel and Next.js after all the controversy and conflicts of interest they've been involved in the past couple of years. Also they somehow managed to make a free complex and full of edge cases non-performant "framework" even more complex with even more edge cases and worse performance and figured out a way to monetize it. I'll admit that's very impressive.
🤷 React was primarily used as a spa framework for a long time. When more people started doing server side rendering, the need for direct access to server resources from server rendered components became a highly requested feature by the community that used React with SSR. Not just in Nextjs, but everywhere. Remix had their own solution to it and lot's of people were building their own solutions using all kinds of dubious means. Your personal hatred towards Vercel doesn't change that.
I'm glad we now have a built in way to do this in React. Imho, the only way they could make RSC better, is by making it easier to host and serve RSCs outside of certain frameworks and hosting platforms.
Excellent, I am glad we agree that RSC were primary designed and work for "certain frameworks and hosting platforms". It's kinda interesting that you think that has anything to do with the community given that statement.
I still don't understand your point about accessing server resources. You can literally do that in any backend SSR framework regardless, if it's Node.js based or another language/platform. Can you give me an example of a backend SSR framework that has no access to server resources. I thought that's the whole point of SSR and I don't see how RSC changed anything about it apart from enabling "certain frameworks and hosting platforms" to charge more money. Can you give me an example outside of these "certain frameworks and hosting platforms"?
That was not at all the statement that I made. Please leave hallucinations to the AI.
The problem is that accessing data on the server that renders your React app is not enough, you need that data inside the scope of a certain component and passing it from the server context into that component was not possible before RSC, except by injecting your data onto the DOM in some non standardized way. People made all kinds of solutions to do just that, because React couldn't do it. Now React can do it.
The only problem is that it doesn't work out of the box, because you need to do stuff on the serverside, hence you need a serverside/fullstack framework that supports RSC, or you need to build your own serverside solution. That last option right now could be made easier yes. That does not at all disqualify RSC, or the fact that it was a community requested feature.
How can you call yourself a full stack developer and claim that "use server" is the standardized way to inject data into the DOM? Give me an example of another framework/language/setup where RSC are necessary. Practically all SSR frameworks inject data into the DOM. I mean isn't that the point of SSR? To inject server data into the template? What missing standardization are you even talking about and how is this the new "standard" way to do it? Can you point me to documentation in Nest.js, Express, Nuxt, ASP.NET, Laravel, Django, Echo, etc planning to adopt "use server"? Or perhaps that would be a thing Vue, Angular, Svelte, Solid, etc are planning to adopt? Like wtf makes RSC standard? How does RSC make things easier outside of Next.js?
I asked for an example outside of Next.js and you provided 0 so far. I am waiting. Also asked for example outside Next.js where the community of any of the popular fullstack frameworks is asking for RSC and can't find any. Give me an example...
Not sure why you drag in other languages and FE frameworks. We're talking about React here and in React this was a problem, whether you can see that through all your hatred or not. I've tried discussing the reasons for that with you, but to be honest I think you're just here to be condescending to others and act like an asshole. 🤷 I wish you the best of luck with that.
Everyone is entitled to their opinion. Calling someone names is real classy, though.
I brought other languages and frameworks because you can practically use react with any of them. You can use react in Express, Nest.js, .NET, Django, Laravel, even in ColdFusion, if you wanted to… It’s to prove my point that SSR does not need another solution to hydrate data in the frontend and “use server” doesn’t do anything outside of Next.js. My point is that RSC were introduced to serve a specific framework and market which is not a coincidence given that Vercel hired the majority of the react team. Your point is that this was a feature requested by the community and I simply asked for proof and examples outside of this conflict of interests. Meanwhile the react community has been requesting a working compiler and signals for years and we’ve got nothing… guess why? Cause it doesn’t solve a problem or pain point for Vercel or Facebook.
You call it hatred, I call it reality. As already said, you are entitled to your opinion, if you think the world is flat, that’s fine. But if you want other people to believe you, you need to prove your point. And so far you provided nothing but hearsay.
What do you recommend?
Objectively speaking Vue strikes the most balance between maturity, performance, simplicity, scalability, devex, ecosystem and learning curve. For all react fans you can write jsx if you want too.
Any of the other modern signal based options could be a good choice too: Solid, Svelte, Angular, etc.
I’ve been writing react for almost 10 years and used most of the other professionally on relatively large multi year projects too. In 2025 react is the wrong choice. It’s basically a jQuery at this point.
Why not preact?
Preact is OK too. It has signals, yay!