【译】为什么我不会使用 Next.js-CSDN博客

为什么我不会使用 Next.js

你有一个新项目要做。或者您有一个现有项目，您有动力升级到更现代的方法。或者，您可能对当前的现代框架不满意，或者对自己进行事后批评，并且正在研究替代方案。无论如何，你必须做出决定。

有很多“现代”框架可供选择。即使您现在没有面临这种选择，您也可能会尝试决定投入时间学习哪个框架，以使自己在未来更具市场竞争力和生产力。

自从 Remix 于 2020 年首次发布以来，我一直在使用它。我非常喜欢它，一年后我加入了该公司，以帮助社区发展。10 个月后，我离开公司，全职在 EpicWeb.dev 工作，在那里我教人们他们需要了解构建全栈应用程序的知识。 Remix 是其中的重要组成部分。 Remix 是一个全栈 Web 框架，致力于解决构建 Web 应用程序的人们所面临的问题——就像 Next.js 一样。

由于 Next.js 是 Remix 的替代方案，人们问我为什么选择 Remix 而不是 Next.js 作为我在 EpicWeb.dev 上教授全栈开发时使用的框架。这些人可能面临着我提到的其中一种情况。所以这篇文章是写给那些人的。

我喜欢将大部分时间和注意力集中在软件开发的积极的一面上。我更愿意写一篇题为“为什么我使用 Remix”的文章，并写一些我喜欢 Remix 的事情（我已经这样做了）。但很多人专门向我询问了 Next.js，这篇文章就是为他们准备的。

我不是来“抨击 Next.js”的。我来这里只是想诚实地表达我个人对 Next.js 的看法和经验。如果您不想听到有关 Next.js 的负面消息，那么我邀请您现在停止阅读，走出去，触摸一些草地。

在继续之前，我需要承认您正在一个使用 Next.js 构建的网站上阅读本文（您可以检查浏览器控制台，您会发现一个全局“NEXT_DATA”变量，而不是“__remixContext”） ` 一）。这是因为 EpicWeb.dev 站点是由一个团队构建的，该团队一直在使用 Next.js 构建软件年，他们做出自己的决定。

这实际上让我有机会在开始之前提出另一个重要观点：

无论你使用什么都可能没问题。

您的工具选择比您使用该工具实现所需结果（良好的用户体验）的技能更重要。

在这篇文章中，我将论证为什么我不会使用 Next.js，因为我认为 Remix 是创建出色用户体验的更好工具。但这并不意味着如果您使用 Next.js，您就是一个失败者或一个坏人。（也就是说，我确实认为如果你使用 Remix，你会更快乐、更有效率，否则我就不会费心写这篇文章了）。

最后，我想提一下，多年来我一直是 Next.js 框架的局外人。我已经很久没有自己用 Next.js 发布过一些东西了。但在你认为我的观点无知之前，你可能想知道这篇文章已经引起了共鸣很多人对该框架的实际体验，所以你’ 我也必须放弃他们所有的经验（我不建议这样做）。

此外，我还关注 Next.js 的发展并听取其他人的经验。我过去作为 Web 开发人员的经验让我对框架所采用的方法有一种直觉，并且我可以很好地了解框架与我的感受不相符的地方。

那么，抛开这个问题，让我们来看看为什么我不会使用 Next.js。

网络平台

我通过 HTTP 部署东西已经有十多年了。我涉足了本机开发（桌面和移动），但我真正在网络上找到了我的家。我想通过一个简短的故事来解释为什么您应该关心包含 Web 平台的框架。

几年前，我在 React 工作，我对测试 React 组件的事实上的标准感到不满意：酶。长话短说，我决定构建测试库，这是现在推荐的测试 React 和其他 UI 库的实用程序。

酶和测试库之间的主要区别之一是，酶为您提供了一个包装器，其中包含一堆（过于）有用（危险）的实用程序，用于与渲染的元素，测试库为您提供了元素本身。为了归结为一个原则，我想说的是，测试库公开了平台 API，而不是包装平台 API。

这样做的主要好处是可转移性。通过专注于标准 API，测试库可帮助人们逐渐熟悉这些 API，这有助于他们在其他地方工作。其他依赖于标准 API 的工具中可用的实用程序与测试库集成，无需特殊适配器，反之亦然。

当然，每个库都有自己的 API。例如，测试库有“findByRole”，您需要了解其输入。但重点是它直接对 DOM 进行操作并将 DOM 节点返回给您。它不是包装 API，而是向您公开这些 API。这是实用性和可转移性之间的平衡。

Next.js 就像酶。 Next.js 具有允许您与请求、标头、cookie 等进行交互的实用程序，而 Remix 通过其“加载器”和“操作”直接向您公开这些 API。在 Remix 中，这些函数接受网络获取“Request”并返回“Response”。如果您需要了解如何返回带有某些设置标头的 JSON，请访问 MDN（事实上的标准 Web 平台文档）而不是 Remix 文档。这样的例子还有很多。当您在 Remix 方面做得越来越好时，您在网络方面也会变得越来越好，反之亦然。

当 Next.js 在静态构建时间方面遇到问题时，建议不要使用 Web 平台的 [Stale While Revalidate Cache Control 指令](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ Cache-Control），他们发明了一种高度复杂的功能，称为“增量静态再生（ISR）”（https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regenesis）实现相同的目标（他们在自己的文档中指出实现了与 SWR 相同的目标）。

当我从 Angular.js 过渡到 React 时，我留下了很多 Angular.js。我为真正擅长 Angular.js 投入的所有时间都感觉是巨大的浪费。我不希望这种事再次发生在我身上。因此，我更喜欢专注于一个框架，它不仅可以从用户体验的角度给我带来我想要的东西，而且还可以给我技能，让我可以在任何我进行 Web 开发的地方使用这些技能。

独立性

您听说过 OpenNext 吗？如果没有，它是这样描述的：

OpenNext 获取 Next.js 构建输出并将其转换为可以作为服务平台部署到任何功能的包。目前仅支持 AWS Lambda。

虽然 Vercel 很棒，但如果您的所有基础设施都在 AWS 上，那么它不是一个好的选择。将其托管在您的 AWS 账户中可以轻松与您的后端集成。而且比 Vercel 便宜很多。

Next.js 与 Remix 或 Astro 不同，没有办法使用无服务器进行自托管。您可以将其作为节点应用程序运行。然而，这与 Vercel 上的工作方式不同。

OpenNext 的存在是因为 Next.js 很难部署在 Vercel 之外的任何地方。我不会在这里做出道德判断。我很欣赏该公司为使自己的托管产品尽可能有吸引力而采取的激励措施，但很明显，这种激励措施已经降低了使 Next.js 易于在任何地方部署的优先级。

我知道 Netlify 团队花费了大量时间来获取 Next.js 支持并跟上 Next.js 的变化。我知道其他基础设施主机是为框架构建适配器的最佳主机（Vercel 管理 Remix 适配器）。但我一直从这些主机那里听说 Next.js 特别难以支持和维护。

我还从许多人那里听说，自己将 Next.js 作为常规 Node.js 应用程序托管也是一个巨大的痛苦。有趣的是，当这篇文章首次发布时，有几个人说他们只是将 Next.js 扔进 Docker 容器中，然后就到此为止了。十分简单。我很高兴这对他们来说已经成功了。

但问题的一部分在于 Next.js 和 Vercel 之间的界限非常细，因此如果您不在 Vercel 上进行部署，那么您实际上使用的是与 Next.js 文档中记录的框架不同的框架，而且并不总是很清楚这些差异是什么，因为 Vercel 没有动力在这方面投入时间。

我们可以争论 Vercel 对于他们当前的做法是对还是错。但事实仍然是，如果 Vercel 的定价或其他问题对您来说成为问题，那么退出 Vercel 也会成为问题。这又回到了激励措施上。

不幸的是，我不断听说 Vercel 的定价已成为很多人的大问题。

再加上据称 Vercel 尚未盈利的事实（即使在 8 年后，他们仍然在积极增长，这是肯定的，但我质疑他们的单位经济效益）。当你把所有的鸡蛋放在那个篮子里时，这应该会让你非常担心。

从一开始，Remix 就是为了部署在任何可以运行 JavaScript 的地方而构建的。这在很大程度上得益于对标准的重视。我非常欣赏 Remix 的这一方面。

Remix 被 Shopify 收购，后者是该项目的出色管理者。 Remix 团队在加入 Shopify 后开始加快发货速度，很大程度上是因为广泛的需求Shopify 使用 Remix 的环境多种多样（营销页面、电子商务、内部和外部应用程序等）。此外，被 Shopify 收购使 Remix 团队能够将所有时间和注意力集中在框架上，而不是弄清楚如何利用该框架来赚钱。

Next.js 正在吞噬 React

我对 Meta 作为一家公司的疑虑总是让我对 Meta 拥有 React 感到有点不安。然而，由于 Vercel 已经雇佣了许多 React 团队成员，这对我来说并没有真正的帮助。从那时起，React 团队就感觉协作性大大降低了。

我自己知道，Vercel 似乎试图模糊 Next.js 和 React 之间的界限。人们对于什么是 React 和什么是 Next.js 有很多困惑，特别是关于服务器组件和 [服务器操作](https 😕/twitter.com/flybayer/status/1716574294728126869）功能。

如果 React 属于一个开放基金会，我会感觉更舒服。但除此之外，如果他们比加入 Vercel 以来更具协作性，那就太好了。

我想你可能会说这是支持 Next.js 的一点，因为至少他们正在获得与 React 更密切合作的好处。但根据我的经验，团队不协作对于他们的软件来说是一个坏兆头。

Redwood 和 Apollo 的维护者因缺乏协作而遇到了一个大问题：

更新：Matt Carroll（React 团队的开发者倡导者）联系我同时我发表了这篇文章，所以这是一个好兆头！

在我的用户身上进行实验

我对 Next.js 团队做出的一些有问题的决定高度关注，这些决定主要是在将实验性功能宣传为稳定时做出的。 Next.js 稳定发布的功能位于 React 金丝雀版本中。老实说，这很有趣，也很悲伤……

你知道“金丝雀”指的是什么吗？它指的是哨兵物种，它们“用于通过提供危险的预先警告来检测人类面临的风险。” 因此，Next.js 正在为自己构建一个金丝雀功能，称其稳定，然后将其发送给所有用户，有效地将您的应用程序变成哨兵物种。您可能不这么认为，也许这只是一个消息传递问题，但我从很多尝试过的人那里听说，他们对 Next.js 的 App Router 的体验远非积极，我认为这很大程度上是因为它的不完整性。他们是金丝雀。

虽然有些人报告使用 App Router 玩得很开心，但我相信他们的很多乐趣来自于减轻“pages”目录的重量并获得嵌套路由功能，而不一定是这些金丝雀功能。

是的，React Server Components 非常酷，我期待在它们[生产就绪]（https://twitter.com/ryanflorence/status/1714340925865148902）时能够使用它们（它们将允许 Remix [卸载] 很多工作](https://twitter.com/ryanflorence/status/1686757173202997249))。

有关这些问题的更多信息，请查看此线程：

太多的魔法

您听说过最小惊喜原则吗？它指出：

系统组件的行为方式应符合大多数用户期望的行为方式，因此不会让用户感到惊讶或意外。

这一点可能存在于“Web 平台”标题下，因为避免让人们感到惊讶的最佳方法是尽可能遵循 Web 平台 API，并减少软件在此基础上所做的“魔法”量。魔法很好，可以减少样板文件等，但我想选择使用这种魔法，这样就清楚发生了什么，而不是自动发生在我身上。

Next.js 在很多方面都违反了这一原则。其中一个例子是决定覆盖全局“fetch”函数以添加自动缓存。对我来说，这是一个巨大的危险信号。正是像这样的决定让我停下来想知道他们还在做什么，如果我决定采用 Next.js，我会感到惊讶。

我们大多数人从 MooTools 时代了解到，覆盖平台的内置功能会导致问题（这就是我们拥有 [String.prototype.includes](https://developer.mozilla.org/en-US/ docs/Web/JavaScript/Reference/Global_Objects/String/includes) 而不是 String.prototype.contains)。这样做会对 Web 平台的未来产生负面影响，这也意味着当您去调试某些东西不起作用时，您必须筛选可用资源以找到“Next.j”s 版本的 fetch”与“Web 平台版本的 fetch”。

复杂性

我不断收到人们的反馈，他们发现 Next.js 变得过于复杂。这也是“魔法太多”的因素之一。 React 有服务器操作以及新的实验性 “taint” API 许多笑话的主题（也是我学到“污点”的另一种定义🤦‍♂️）。

我对 React 添加对突变的内置支持的前景感到兴奋。但我绝对担心它们改变语义网络表单的工作方式。这些事情中的每一个都会增加复杂性。

我真的很感激 Remix 团队由分享我的原则的人领导，并将确保一旦包含这些类型的功能，它们就不会下降同样的道路增加了复杂性。事实上，Remix 团队致力于在未来减少总体 API 占用量，而不是增加它。这引出了我的下一点。

稳定

Next.js 的版本为 13。React Router（与 Remix 由同一团队构建）已经存在了更长的时间，并且只有版本 6。Remix 的版本 1 已经存在了近两年零一个月之前发布了版本 2。由于 Remix 团队对稳定性的重视，它是有史以来最无聊的主要版本升级的 Web 框架。

我需要承认 Next.js 团队非常关心通过 codemods 简化升级路径。我很理解框架需要随着时间的推移而发展。但我看到很多人抱怨 Next.js 团队在 Next 13 中推出的内容不稳定，并且包装金丝雀功能并称其为稳定，这对我来说并不合适。

今年早些时候，Remix 团队分享了他们的计划，即使用名为“future flags的策略，将版本 2 的功能作为版本 1 的可选部分发布。 ” 效果非常好，大量积极开发的 Remix 应用程序在不到一天的时间内就得到了升级。

Remix 团队非常关心稳定性。这就是为什么他们几年前没有跟上潮流并实现对 React Server 组件的支持，尽管每个人都要求他们这样做。这也是为什么在 React Router 的 8 年里实际上只发生了一个重大变化。

这种稳定性对我和我构建的应用程序产生了重大影响。有一些库我总是害怕升级，因为当我尝试更新所有代码以适应新版本时，我曾经经历过数小时的困惑。对于像 Web 框架这样有影响力的东西，我宁愿没有这种感觉。 Remix 在这方面是一份礼物。

能力

您可能期望这篇博文将 Next.js 与 Remix 等其他框架的特性和功能进行比较。但事实是，您可以使用这两个框架构建很棒的东西。我想指出的是，特性比能力更重要。我个人觉得 Remix 的成功坑比 Next.js 更宽，但我不会费尽心思去描述原因。无论如何，很多东西都是相当主观的。

当 Remix 团队重写 Next.js 电子商务演示来回答“Remix vs Next.js”问题时，它很好地证明了 Remix 带来了使用更少的代码获得更好的用户体验（这是用户体验的重要输入）。从那时起，Next.js 已将其更新为使用 App Router（他们称之为稳定版，但正如我已经提到的那样依赖于金丝雀功能），因此我认为值得再次进行比较。自那篇文章撰写以来，Remix 还学到了一些新技巧，例如乱序流。