超越 Next.js：探索替代的 React 服务器组件框架

React Server Components (RSC) 目前的进展如何？

当 2020 年底 React 团队引入“零捆绑大小 React 服务器组件”概念时，许多人一直并且仍然难以理解它。现有框架都不支持新概念，原型也没有提供构建现实世界应用程序的可用基础。

现在，四年多过去了，所需的 React 版本仍处于测试阶段，尚未发布到生产环境，并且支持它的唯一大型知名框架由前 React 团队成员组成。对于少数试图提供基于 RSC 的替代框架的开发人员来说，这是一个非常悲伤的情况。

为什么我需要 RSC？

普通的 React 是一个仅专注于提供快速声明性解决方案来在浏览器中构建应用程序的库。浏览器中的应用程序始终需要服务器来获取和存储其状态。基于这一事实，大量的解决方案被开发出来并存在于 React 客户端生态系统中。当越来越多的人开始使用 Typescript 创建后端时，下一个趋势是带有类型化接口的 RPC 的复兴，它在后台创建了 api 端点。

查看 RSC 的这些要求，很快就会发现所有这些都在 RSC 的范围内，因为它们提供：

• 可以返回类型化值和承诺的类型化服务器操作
• 单个服务器请求更改服务器上的数据并更新客户端 UI
• 在服务器上渲染组件，并且仅将序列化的渲染树流式传输到支持乱序渲染的客户端

这允许应用程序开发人员使用 React 来定义所有组件，无论它们是在客户端还是服务器上渲染。这种集成环境降低了现代应用程序的复杂性，并消除了后端和前端中重复的业务逻辑的冗余。

哪些框架支持 RSC？

由于 React 库仍是官方测试版，因此它们都不应该被视为生产就绪：

• Next.js v15
• 哇库
• 反应服务器
• RedwoodJS v9 - 仍在开发中

目前只有 Next.js 在某种程度上可用于生产。他们的版本 15 是 RSC 的第四次迭代，从 2021 年底开始发布版本 12。

除了列出的框架之外，这里还有一些存储库，其中包含构建 RSC 框架的蓝图 - 如果您想了解更多有关内部结构的信息，请使用它们：

• 文熙
• 双倍
• 科特坎
• r19

如果您了解更多框架，请在评论中提供它们的链接。

是什么让 RSC 难以在框架中实现？

基于 React 客户端应用程序现有的优秀捆绑器进行转录和捆绑非常简单。有多种选项可以执行此操作，最常用的选项之一是使用 ViteJs 作为开发服务器和捆绑器。提供 JavaScript 前端和后端堆栈的框架仍然必须提供自己的解决方案来处理开发和生产中的打字稿和捆绑。

使用 RSC，捆绑器需要处理至少三个转录和捆绑管道：

1. 浏览器客户端
2. SSR 服务器
3. RSC 组件渲染器和灭菌 API
4. 可选中间件

在 Vite 版本 6 发布之前，这需要大量特殊代码来提供有效的解决方案。 Next.js 只是在版本 15 中切换到 Turbopack 来修复由于 webpack 的复杂性和使用而导致的滞后问题，而 webpack 从来都不是为了处理此类问题而构建的。
Vite 6 的新功能是许多针对框架作者的，并通过他们的新环境 api 提供了一个很好的解决方案。

基于现在组件在完全不同的环境中渲染的事实，需要构建每个React库，通过提供替代内容来处理每个环境的限制。目前，大多数库都可以处理在服务器上渲染以创建 SSR 内容，但许多浏览器特定的 API 缺失。渲染 RSC 组件会给不同的 React 服务器库带来额外的限制，例如，它不支持 React 上下文和状态以及需要它为所有子组件提供主题的中断库。并且库需要在 packages.json 和 ESM-Modules 中为库和所有相关子库提供适当的导出选项。

RSC 的 React 库没有提供的第二个部分是路由器。如果没有处理客户端和服务器路由的路由器，React 服务器组件不知道要在服务器上呈现哪个状态。这就是为什么每个框架都有自己的路由器实现的原因，并且在其 api 标准化之前，为一个框架开发的服务器和客户端组件将需要更改以与另一个框架一起使用。

真正的 RSC 框架的所有要求

• React 服务器组件
  • 没有服务器的服务器组件
  • 带有服务器的服务器组件
  • 异步组件与服务器组件
• 服务器操作
  • 从服务器组件创建服务器操作
  • 从客户端组件导入服务器操作
  • 用动作组合服务器动作
  • 带有服务器操作的表单操作
  • 使用 useActionState 的服务器操作
  • 使用 useActionState 进行渐进增强
  • 对服务器的单个请求，响应中包含 UI 的更新数据
• 指令
  • “使用客户端”可让您标记在客户端上运行的代码。
  • 'use server' 标记可以从客户端代码调用的服务器端函数。
• 捆绑 DEV 和 PROD 中的所有三个目标
• 客户端路由 API
• 服务器端路由API

有关 React Server 组件的更多详细信息可以在 React 官方文档中找到。

元框架的可选要求：

• 服务器端渲染（SSR）
• 静态站点生成 (SSG)
• 嵌套布局
• 流媒体
• 文件系统路由器
• 非 React API 端点
• 中间件
• 多个部署目标
• 支持边缘运行时（AWS Lambda@Edge、Cloudflare）

Next.js - 为什么要寻找替代选项？

事实上，Next.js 15 是最主流的 RSC 框架，为什么我需要考虑替代框架？

这样做的原因始终基于要达到的目标，但我会尝试列出一些考虑其他选项有意义的原因：

1. Next.js 是一个复杂的框架，它试图涵盖许多可能与给定项目不相关的不同用例
2. 基于所有提供的功能的复杂性和使用情况，除 Vercel 之外的其他云环境的部署不受官方支持，并且需要付出巨大的努力才能与每个次要版本和主要版本的托管要求发生的变化保持同步。
3. 直到版本 15 将捆绑程序更改为 Turbopack，开发体验缓慢且迟缓

请记住，本文仅关注提供 RSC 的替代方案，但还有更多框架提供与 RSC 几乎相似的功能，并且可能是比本文列出的 RSC 框架更好的替代方案。

Waku - 最小的 React 框架

由加藤大师开发：

Waku (wah-ku) 或わく在日语中的意思是“框架”。作为最小的 React 框架，它旨在加速初创公司和机构的开发人员构建中小型 React 项目的工作。其中包括营销网站、轻型电子商务和网络应用程序。

我们推荐用于重型电子商务或企业应用程序的其他框架。 Waku 是一种轻量级替代方案，为服务器组件时代带来有趣的开发人员体验。是的，让 React 开发再次变得有趣！

使用 Waku 启动一个新项目非常简单，您将获得一个使用 tailwind 设置的入门模板：
npm create waku@latest

涵盖了所有基本要求除了在使用变异服务器操作时在单个请求中返回客户端组件的更新之外。目前，任何服务器突变都需要在客户端组件中使用 router.reload() 刷新客户端路由器，这会导致向服务器发出第二个请求，以将更新后的数据作为 RSC 流加载。

以下可选要求仍在开发中：

• 嵌套文件系统路由
• 非 React API 端点

支持许多部署目标：Vercel、Netlify、Cloudflare、PartyKit、Deno、AWS Lambda、NodeJS

基于捆绑的复杂性，请准备好在许多第三方库中出现问题：
https://github.com/dai-shi/waku/issues/423

@lazarv/react-server - 使用服务器端渲染构建 React 应用程序的最简单方法

由 Viktor Lázár 开发：

我创建了 @lazarv/react-server 因为我想通过 Vite ❤️ 使用 React 服务器组件和服务器操作。对于大多数小型应用程序来说，Next.js 太多、太重、太慢。我希望获得与使用 Node.js 运行简单 JavaScript 文件相同的体验。这个框架试图尽可能地不发表意见。你可能可以实现你想要的任何事情。唯一的限制是它将使用自己的 React 版本。您甚至不需要在项目中安装 React。这一切都包含在框架中。我希望您会喜欢使用这个框架，就像我喜欢创建它并使用它来创建本文档一样。 - 拉扎尔夫

使用这个框架学习 React 服务器组件是一件轻而易举的事！您只需要一个包含有效反应服务器组件并运行命令的文件：

./App.jsx

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

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

教程部分有一个关于如何入门的很好的文档和几个示例项目。

涵盖所有基本要求除了在使用变异服务器操作时在单个请求中返回客户端组件的更新。

由于运行时依赖于 NodeJS API，因此其他运行时例如目前不支持（AWS Lambda@Edge、Cloudflare）。

此外还存在以下功能：

• 访问服务器组件和操作中的 HTTP 上下文
• 缓存任何服务器数据和服务器响应，并根据关键订单标签重新验证
• 错误处理
• 部分预渲染 - 将 JSX 页面的一部分定义为静态 shell
• NodeJS 集群模式
• 微前端 - 将您的应用程序分成更小、更易于管理的部分。使用 RemoteComponent 组件从远程 URL 加载微前端，并使用服务器端渲染在您的应用程序中渲染它

部署目标：NodeJS、Vercel - 开发中的适配器：Netlify、Cloudflare、sst

支持开箱即用的 Tailwind CSS、TanStack 查询、Mantine UI、Material UI。

RedwoodJS - 有效的单一开发框架

由汤姆·普雷斯顿-沃纳提供：

Redwood 是全栈 JavaScript 应用程序框架。
包括电池、后端、React、约定和意见。

仍在开发中并且仅适用于 Node v20 和 Yarn 4：

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

然后您需要启用一些实验性功能：

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

最后，构建并服务：

npx -y create-redwood-app@canary -y ~/rsc_app
cd ~/rsc_app

作为 setup-rsc 命令的一部分，为您创建了一个准系统 RSC 应用程序，演示了服务器组件内部渲染的客户端组件

部署目标：Vercel、Netlify、Render、GCP 或 AWS（通过 Coherence）、AWS（通过 Flightcontrol）、NodeJS

比较：Next.js 与替代方案

	Next.js	WAKU	React-server	RedwoodJS
DEV-Environment / Bundling	Turbopack	Vite 5	Vite 6	Vite
Rendering	SSR, ISR, SSG, CSR	SSR, SSG, CSR	SSR, SSG, CSR, Micro-Frontends	SSR, SSG, CSR
Caching Layers	Yes	No	Yes	??
Deployment Target	Vercel, NodeJS	Vercel, Netlify, Cloudflare, Deno, AWS Lambda, PartyKit, NodeJS	Vercel, NodeJS, sst (AWS Lambda)	Vercel, Netlify, AWS, NodeJS
Community	Very Big	Tiny	Just Starting	Small
Open Source Financing	Vercel	Donations	Donations	Privately Funded by a Rich Guy

结论

要点回顾：

• RSC 为现代 Web 开发提供了强大的范例。
• Next.js 很优秀，但不是唯一的选择。
• 替代方案提供了满足不同需求的多种功能，但错过了单一请求突变 UI 更新。
• React 生态系统中的图书馆尚未准备好拥抱 RSC

尝试框架以找到最适合您的项目的框架。

以上是超越 Next.js：探索替代的 React 服务器组件框架的详细内容。更多信息请关注PHP中文网其他相关文章！