React 窝里斗：Next vs Remix 的开发者困境今天，我们来深度学习两个人气爆棚的宿敌：Next 和 Rem

大家好，这里是大家的林语冰。

React 生态系统元气满满，孵化了有望彻底改变 Web 开发的框架。今天，我们来深度学习两个人气爆棚的宿敌：Next 和 Remix。

Next 是 SSR（服务端渲染）人气最高的 React 框架之一，它由来已久。Next 提供了优秀的开发体验和开发者想要的全家桶功能。

Remix 是 SSR 领域的超新星，由“React Router 之父”创建。Remix 提倡全栈开发方法，并带来多项创新功能。随着 2022 年 Remix 的开源推广，开发者开始思考哪个框架更适合开发应用程序。

在本文中，我们会剖析一下 Next vs Remix 的优缺点，辅助我们明智选择。

免责声明

本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考。英文原味版请传送 Next.js vs. Remix - A Developer's Dilemma。

1. 路由

Next 有两个不同的路由器：App Router 和 Pages Router。App Router 是一个较新的路由器，它允许我们使用 React 的最新功能，比如 RSC（服务器组件）和流媒体。Pages Router 是最初的 Next 路由器，它允许我们构建 SSR 的 React 应用程序，并继续支持旧版 Next 应用程序。

至于 App Router，Next 13 使用基于目录的路由，其中​ ·/app 下名为 page.tsx 的任意文件都会被构建为路由。app 目录中的文件夹可以包含：

• layout.tsx：用于布局
• page.tsx：用于使该路由公开访问
• loading.tsx：用于定义加载状态
• error.tsx：用于错误处理

如果想要创建嵌套路由，我们可以将文件夹相互嵌套。

Next 路由：

Next 嵌套路由文件夹结构：

Remix 2 使用基于扁平文件的路由系统。在 /app/routes 文件夹中，我们可以通过添加新组件来创建新路由。创建嵌套路由是通过在文件名中使用 . 点分隔符来完成的。

举个栗子，如果我们想在 Remix 应用程序中创建 /concerts/trending 路由，我们会添加一个名为 concerts.trending.tsx 的新文件。

现在，如果我们比较这两个框架的路由机制，就会发现两者基于文件系统的路由几乎殊途同归，而且感觉这是正确的选择。

2. 数据请求

Next 提供了若干数据请求方法：

1. getServerSideProps：在每次请求期间从服务器请求数据。这用于 SSR，即当客户端请求页面时请求数据。
2. getStaticProps：在构建时请求数据，生成带有预渲染内容的静态 HTML 页面。
3. getInitialProps：在服务器和客户端上运行，支持初始渲染和客户端水合作用（hydration）的数据请求。它是一个遗留 API。
4. fetch：Next 扩展了原生 fetch Web API，允许我们为服务器上的每个 fetch 请求配置缓存和重新验证行为。fetch 与 async/await 可以在 RSC、路由处理程序和服务器操作（Server Action）中使用。

在 Remix 中，数据是在加载器中请求的。每个路由可以定义一个加载器函数，该函数在渲染时向该路由提供相关数据。useLoaderData 向组件提供加载程序的数据。加载器能且仅能在服务器上运行。

Next 似乎十分适合静态和动态内容混合的应用程序，优先考虑灵活性和自定义。Remix 的数据请求方法可以更好地控制数据加载和依赖关系。

3. 数据突变

在处理突变（mutations）时，我们一般通过向后端服务器发送 API 请求，然后更新本地状态以反映更改来处理它们。

这两个框架都旨在通过将突变处理直接集成到其核心功能中，从而彻底改变突变处理。

在 Next 13.4 之前，在服务器上创建和执行操作的唯一方法是，创建 API 路由并更新状态。

Next 13.4 引入了服务器操作来处理数据突变，简化开发体验，并改善用户体验。

Remix 会自动使 UI 与持久服务器状态保持同步。它分三个步骤发生：

1. 路由加载器向 UI 提供数据
2. 表单发布数据给更新持久状态的路由操作
3. 页面上的加载器数据会自动重新验证

Remix 鼓励将用户执行操作的应用程序的各个部分保留为 HTML 表单。每当用户触发表单提交时，它就会调用该操作。执行操作后，Remix 会通过浏览器 fetch 请求，重新获取该路由的所有加载器并刷新 UI，确保 UI 始终与数据库保持同步。这被称为 Remix 的“全栈数据流”（full-stack data flow）。

我的个人心证是：

1. Next 服务器操作与 React 生态系统和 React API 相关联。而 Remix 是根据网络平台的功能实现的，并且与网络的工作方式密切相关。
2. Next 操作以组件为中心。而 Remix 操作则以路由为中心，因此不像组件那样可组合。
3. 在 Next 中，我们需要手动通知重新验证路径，而 Remix 会自动重新验证。

这些是 Next vs Remix 的权衡，我们可以决定哪些是我们的底线，哪些是我们的需求，并做出相应的决定。

4. 错误处理

Next 和 Remix 都提供了在 Web 应用程序中优雅处理错误的机制。

在 Next 中，每个路由分段（route segment）中有一个单独的 error.js 文件，用于渲染该路由的错误状态。error.js 文件约定允许我们自动将路由分段及其嵌套子级包裹在 React 错误边界（Error Boundary）中，优雅处理嵌套路由的意外运行时错误。

在 Remix 中，要渲染路由分段的错误状态，我们可以导出 ErrorBoundary。

Next 和 Remix 都可以处理服务器或浏览器可能发生的意外错误，以及 404 等预期错误。

5. 社区支持

Next 是一个成熟的框架，拥有约 12 万 GitHub 收藏。它拥有庞大的社区和生态系统，在寻找问题、插件或集成的解决方案时具有显著优势。

Remix 拥有大约 3 万 GitHub 收藏和不断增长的社区。

如果应用程序不复杂，并且不需要社区的太多辅助，那么优先选择 Remix。如果应用程序需要一个具有更广泛功能和大量用户社区的框架，Next 是一个不错的选择。

6. 学习曲线

Next 学习成本较高，它提供了很多选择。如果开发者没有正确使用它们，低阶控制可能会搬起石头砸到自己的猫。

Remix 比较精简，它只提供唯一方案，并抽象出很多事情。

7. 部署

在 Vercel 之外部署 Next 可能极具挑战，Vercel 是一个出色的平台，但如果我们的基建位于 AWS 上，那么可能并不理想。在我们的 AWS 账户中托管 Next 可以更轻松地与我们的后端集成，并且通常比 Vercel 更有性价比。

虽然 Next 没有对 Serverless 自托管的原生支持，但我们可以将其作为 Node 应用程序运行。但是，此方法可能无法提供与使用 Vercel 相同的好处。

幸运的是，有一个新的开源 Next Serverless 适配器 OpenNext。该适配器采用 Next 构建输出，并将其转换为可以部署到任何 FaaS（函数即服务）平台的包，从而使部署更加灵活。

Remix 设计用于在任何支持 JS 执行的平台上部署。这主要是由于其对标准的关注。

8. 大厂背书

Next 由 Vercel 维护。React 团队正在与 Next 团队密切合作，推出 RSC 等新功能。

Remix 于 2022 年与 Shopify 强强联手！在 Shopify 的管理下，Remix 获得了商业领域知名领导者的长期支持和背书。

9. 公司用户

Next：

• Netflix Jobs（网飞就业）
• TikTok（抖音国际版）
• Notion

Remix：

• NASA（美国宇航局）
• Shopify（跨境电商）
• Docker

Next 和 Remix 在不同领域都表现出色，两者旗鼓相当。

然而，“最佳框架”取决于项目的独特需求：

• Next 适合大型项目、功能丰富的框架，以及通过广泛支持快速落地。
• Remix 适合性能关键型项目、流畅的用户体验、解决不太复杂的问题，以及探索现代方法的意愿。

本期话题是 —— 你是 Next 爱好者呢，还是 Remix 发烧友呢？

欢迎在本文下方自由言论，文明共享。谢谢大家的点赞，掰掰~

《前端猫猫教》每日 9 点半更新，坚持阅读，自律打卡，每天一次，进步一点。