Beyond Next.js: Exploring Alternative React Server Component Frameworks

8 min readDec 5, 2024

What is the current deal with React Server Components (RSC)?

When in late 2020 the React team introduced the “Zero-Bundle-Size React Server Components” concept, many people have been and are still struggle to understand it. None of the existing frameworks supported the new concept and the prototypes did not provide a usable base to build real world applications.

Now, more than 4 years later, the required version of react is still in beta and not released for production and the only big and well-known framework which supports it is staffed by ex-react team members. This is a very sad situation for the few developers which have tried to offer alternative frameworks based on RSC.

Why would I need RSC?

The normal React is a library which only focused on providing a fast declarative solution to build application in the browser. Applications in the browser always need a server to fetch and store their state. Based on this fact a huge number of solutions have been developed and exist in the react client eco system. When more and more people started to create their backend with Typescript, the next trend where a renaissance of RPC with typed interfaces which created the api end points in the background.

Looking at RSC with these requirements it becomes quickly clear that all of this has been in the scope for RSCs as they provide:

typed server actions which can return typed values and promises
single server request to mutate data on the server and update client-side UI
render components on the server and only stream a serialized render tree to the client which support out of order rendering

This allows application developers to use react to define alle components using react independent of them being rendert on the client or on the server. This integrated environment reduces the complexity of modern apps and gives removes the redundance of duplicated business logic in backend and frontend.

What frameworks support RSC?

As the react library is official still beta none of them should be seen as production ready:

Next.js v15
Waku
react-server
RedwoodJS v9 — still in Development

Currently only Next.js is somewhat usable for production. Their Version 15 is the 4th iteration on RSC which started late 2021 with Version 12.

Beyond the listed framework, here are some more repositories with blueprints on building a RSC framework — use them if you want to learn more about the internals:

If you know from more frameworks please provide links to them in the comments.

What makes RSC hard to implement in frameworks?

Transcribing and bundling, based on the great existing bundlers of a react client app is simple. There are multiple options to do this and one of the most used one is by using ViteJs as the development server and bundler. Frameworks which provided a JavaScript frontend and backend stack still had to provide their own solution to handle typescript and bundling in development and for production.

With RSC a bundler needs to handle a minimum of three transcribe and bundle pipelines:

Browser Client
SSR Server
RSC Component renderer and sterilization api
optional middleware

Until the release of Vite version 6 this needed a lot of special code to provide a working solution. Next.js just switch to Turbopack in version 15 to fix the laggings they got based on the complexity and the use of webpack which was never build to handle this kind of problems. Vite 6 new features are many targeting framework authors and provide a great solution with their new environmental api.

Based on the fact that now components are rendered in completely different environment, each react library need to be built to handle the restrictions of each of these environments by providing alternative content. Currently most libraries can handle being rendered on the server to create SSR content, where many browsers specific APIs are missing. Rendering RSC components brings an additional limitation with a different react server library which for example do not support react context and state and break libraries which need this to provide theming to all child components. And libraries need a proper export option in packages.json and ESM-Modules for the library and all related sub libraries.

The second piece not provided by the react library for RSC is the router. Without a router which handles client and server routing, react server component do not know which state to render on the server. This is the reason why each of the framework comes with their own implementation of a router and until the api for this gets standardized, server and clients components developed for one framework will need to be changed to work with another framework.

All requirements for a true RSC framework

React Server Components
+ Server Components without a Server
+ Server Components with a Server
+ Async components with Server Components
Server Actions
+ Creating a Server Action from a Server Component
+ Importing Server Actions from Client Components
+ Composing Server Actions with Actions
+ Form Actions with Server Actions
+ Server Actions with useActionState
+ Progressive enhancement with useActionState
+ Single Request to Server with updated data for the UI in the response
Directives
+ 'use client' lets you mark what code runs on the client.
+ 'use server' marks server-side functions that can be called from client-side code.
bundling for all three targets in DEV and PROD
clientside routing api
serverside routing api

more details on React Server Components can be found in the [official React documentation] ( https://react.dev/reference/rsc/server-components).

Optional Requirements for meta-frameworks:

Server-side Rendering (SSR)
Static Site Generation (SSG)
Nested Layouts
Streaming
Filesystem router
none-React API endpoints
Middleware
Multiple deployment targets
Support for Edge-Runtimes (AWS Lambda@Edge, Cloudflare)

Next.js — why look for alternative options?

Based on the fact, that Next.js 15 is the most majored RSC framework, why should I have a need to look at alternative frameworks?

The reasons to do this are always based on the goal to reach, but I will try to list some reasons why it makes sense to look at the other options:

Next.js is complex framework which tries to cover many different use cases which might not be relevant for the given project
based on the complexity and usage of all provided features, the deployment to other cloud environments beside Vercel are not official supported and require some huge effort to stay in sync with the changes happening to this hosting requirements with each minor and major versions.
until Version 15, which changes the bundler to Turbopack, development experience was slow and sluggish

Please keep in mind, that this article only focuses on alternatives which provide RSC, but there are many more frameworks which provide nearly similar features to RSC and could be much better alternatives than the RSC frameworks listed in this article.

Waku — The minimal React Framework

Developed by Daishi Kato:

Waku (wah-ku) or わく means “framework” in Japanese. As the minimal React framework, it’s designed to accelerate the work of developers at startups and agencies building small to medium-sized React projects. These include marketing websites, light ecommerce, and web applications.

We recommend other frameworks for heavy ecommerce or enterprise applications. Waku is a lightweight alternative bringing a fun developer experience to the server components era. Yes, let’s make React development fun again!

Starting a new project with Waku is simple and you will get a starter template which is setup with tailwind: npm create waku@latest

All base requirements are covered including returning updates to client side components in a single request when using mutating server actions.

Waku single request mutation and UI update

The following optional requirements are still in development:

Nested Filesystem Routes
none-React API endpoints

Supports many deployment targets: Vercel, Netlify, Cloudflare, PartyKit, Deno, AWS Lambda, NodeJS

Based on the complexity of bundling be prepared to have problems with a lot of third-party libraries: https://github.com/dai-shi/waku/issues/423

@lazarv/react-server — The easiest way to build React apps with server-side rendering

Developed by Viktor Lázár:

I created @lazarv/react-server because I wanted to use React Server Components and Server Actions using Vite ❤️. For most small apps Next.js was too much, too heavy and slow. I wanted to have the same experience as you run a simple JavaScript file using node.js. This framework is trying to be non-opinionated as much as possible. You can achieve possibly anything you want. The only restriction is that it will use it’s own React version. You don’t even need to install React in your project. It’s all included in the framework. I hope you will enjoy using this framework as much as I enjoyed creating it and using it to create this documentation too. — lazarv

Learning react server components is a breeze with this framework! A single file with a valid react server component and running the command is all you need:

./App.jsx

export default function App() {
  return <h1>Hello, World!</h1>
}

npx @lazarv/react-server ./App.jsx

There is a good documentation on how to get started and a couple of example projects in the tutorial section.

All base requirements are covered including returning updates to client side components in a single request when using mutating server actions.

As the runtime depends on NodeJs API other runtimes e.g. (AWS Lambda@Edge, Cloudflare) specific runtimes are currently not supported.

Additionally the following feature exist:

Access HTTP context in server components and actions
Caching any server data and server response with revalidation based on key ord tags
Error handling
Partial pre-rendering — define parts of a JSX page as static shell
NodeJS Cluster mode
Micro-frontends — split your application into smaller, more manageable pieces. Use the RemoteComponent component to load a micro-frontend from a remote URL and render it in your application using server-side rendering

Deployment targets: NodeJS, Vercel — Adapters in Development: Netlify, Cloudflare, sst

Supports out of the box Tailwind CSS, TanStack Query, Mantine UI, Material UI.

RedwoodJS — The Single-Dev Framework that Just Works

Provided by Tom Preston-Werner:

Redwood is the full-stack JavaScript application framework. Batteries, backend, React, conventions, and opinions included.

Still in development and only works with Node v20 and Yarn 4:

As part of the setup-rsc command a barebones RSC app is created for you, demonstrating a client component rendering inside of a server component

Deployment targets: Vercel, Netlify, Render, GCP or AWS via Coherence, AWS via Flightcontrol, NodeJS

Comparison: Next.js vs. Alternatives

Conclusion

Recap of Key Takeaways:

RSC provides a powerful paradigm for modern web development.
Next.js is excellent but not the only choice.
Alternatives offer diverse capabilities for different needs but miss the single request mutation UI updates.
Libraries in the React Ecosystem are still not ready to embrace RSC

Try out frameworks to find the best fit for your project.

Originally published at https://www.heissenberger.at.