为什么我不使用 Next.js？
【CSDN 编者按】Next.js是 Remix 的一个非常流行的替代品，本文作者想诚实地表达个人对 Next.js 的看法和使用体验，并非有意抨击 Next.js。
原文链接：https://www.epicweb.dev/why-i-wont-use-nextjs?trk=feed_main-feed-card_feed-article-content
未经允许，禁止转载！
作者 | Kent C. Dodds 译者 | 弯月
责编 | 夏萌出品 | CSDN（ID：CSDNnews）
在开启新项目，升级已有项目，或者因对当前的现代框架不满而研究替代方案时，你必须决定使用哪个框架。然而，我们有很多“现代”框架可供选择。即便当前你没有面临这种选择，也需要决定投入时间学习哪个框架，以便让自己更具市场竞争力。
自 Remix 于 2020 年首次发布以来，我一直在使用它。我非常喜欢这个框架，所以我加入了该团队，与他们共事了 10 个月，如今我依旧非常推荐 Remix，而且还在教授 Remix 的课程。Remix 是一个全栈 Web 框架，致力于解决构建 Web 应用程序时面临的各种问题，与 Next.js 十分相似。
Next.js 是 Remix 的一个非常流行的替代品，经常有人问我为什么在教授 Web 开发框架的课程时选择 Remix 而不是 Next.js。因此，我想通过本文做出解答。
我无意通过本文来抨击 Next.js，我只是想诚实地表达个人对 Next.js 的看法和使用体验。如果你不想听到有关 Next.js 的负面消息，现在就可以关闭本文了。
在深入讨论之前，我想阐述另一个重要观点：无论使用任何框架实际上都没问题。相较于工具的选择，使用工具实现所需结果（良好的用户体验）的水平更重要。在这篇文章中，我将阐述为什么我不会使用 Next.js，因为我认为就创建出色用户体验而言 Remix 是一款更优秀的工具。但这并不意味着使用 Next.js 不好。
最后，我想提一下，多年来我一直是 Next.js 框架的局外人。我已经很久没有用 Next.js 发布产品了。话虽如此，我也在关注 Next.js 的发展，而且还听取了其他人的经验。以往的经验让我对各个框架采取的方法有一种直觉，而且我能体会到各个框架与我的感觉不符的地方。
下面，我们来看看为什么我不使用 Next.js。
Web平台
十多年来，我一直在通过 HTTP 部署产品。我也曾涉猎过原生开发（桌面和移动），但 Web 让我有一种归属感。几年前，我曾接触过 React，我不太满意测试 React 组件的标准工具：enzyme。长话短说，最后我决定构建 Testing Library，而该库现已成为 React 和其他 UI 库推荐的测试工具。
enzyme和 Testing Library 之间的主要区别之一是，enzyme 返回的是一个包装器，其中包含一堆（过度）有用（危险）的实用程序，用于访问渲染过的元素，而 Testing Library 则直接访问渲染过的元素，为你提供了元素本身。我想表达的是，enzyme 包装了平台 API，而Testing Library 公开了平台 API。
这样做的好处主要是可转移性。Testing Library 主要关注标准 API，可以帮助人们熟悉这些 API，让他们将所学的经验用于其他地方。此外，其他依赖于标准 API 的工具中的实用程序也可与Testing Library 集成，无需特殊适配器，反之亦然。
当然，每个库都有自己的 API。例如，Testing Library 库有 findByRole，你需要了解其输入。但重点在于，它可以直接操作 DOM，并返回 DOM 节点。它不是包装 API，而是公开这些 API。这样就可以平衡实用性和可转移性。
而 Next.js 就像 enzyme 一样。Next.js 提供了很多实用程序，可方便你与请求、标头、cookie 等进行交互；而 Remix 则通过 loader 和action 公开了这些 API。在 Remix 中，这些函数接受请求并返回响应。如果你需要了解如何返回带有某些设置标头的 JSON，可以查看 MDN（Web 平台文档的事实标准 ），而不是 Remix 文档。这样的例子还有很多。随着你越来越熟悉Remix，Web 开发水平也越来越高，反之亦然。
当年我从 Angular.js 过渡到 React，我感觉投入到 Angular.js 上的时间都是巨大的浪费。我不希望这种事再次发生在我身上。因此，我更喜欢专心研究一个框架：这个框架不仅可以从用户体验的角度为我提供想要的功能，而且还可以为我提供可应用于任何 Web 开发所需的技能。
独立性
你听说过 OpenNext 吗？官方描述如下：
OpenNext接受 Next.js 构建输出，并将其转换为可部署到任何 FaaS 平台的包。目前仅支持 AWS Lambda。
虽然 Vercel 很棒，但如果你的所有基础设施都在 AWS 上，那么 Vercel 不是一个好的选择。将其托管在 AWS 账号中可以轻松与你的后端集成。而且比 Vercel 更便宜。
Next.js与 Remix 或 Astro 不同，无法使用无服务器实现自托管。你可以将其作为 Node 应用程序运行。然而，这与 Vercel 上的工作方式不同。
OpenNext之所以存在是因为 Next.js 很难部署到 Vercel 之外的任何地方。虽然Vercel为自己的托管服务产品提供了优惠政策，但很明显，他们的优先级都放在了优惠政策上，而并没有意愿将Next.js变成在任何地方都可以部署。
许多人都认为将 Next.js 作为常规 Node.js 应用程序托管非常痛苦。我知道 Netlify 团队花费了大量时间来获取 Next.js 的支持并跟上 Next.js 的变化。
至于 Vercel 当前的做法是对还是错，见仁见智。但如果你遇到 Vercel 的定价或其他问题，那么退出Vercel 也会成为问题。说到底还是上述提到的优惠政策。
另外，据称 Vercel 尚未盈利，将所有鸡蛋都放在这个篮子里未免让人忧心。
Remix从一开始就是为了部署在任何可以运行 JavaScript 的地方而构建的。这在很大程度上得益于对标准的重视。我非常欣赏Remix 的这一方面。
Next.js正在吞噬 React
我对 Meta 这家公司有一些疑虑，因此对于他们拥有的 React 也感到有点不安。Vercel 收买了如此多的 React 团队成员，但我的不安并没有得到缓解。从那以后，React 团队的协作性大大降低了。
我知道，Vercel 在试图模糊 Next.js 和 React 之间的界限。人们对于什么是 React 和什么是 Next.js 充满了疑惑，特别是在服务器组件和服务器操作功能方面。
如果 React 属于某个开放基金会，我会感觉更舒服。此外，如果在加入 Vercel 后，他们能加强协作，那就太好了。
我想你可能会说这不正是我们支持 Next.js 的原因吗，因为至少他们与 React 展开更密切的合作会更有好处。但根据我的经验，对于软件来说，团队缺乏协作是一个坏兆头。
拿用户做实验
Next.js团队在宣传中将一些实验性功能说成了稳定功能，这一点让我十分担心。Next.js 发布的稳定功能依赖于 React 的金丝雀版本。老实说，这很有趣，也很令人伤心……
你知道“金丝雀发布”指的是什么吗？因为金丝雀对矿场中的毒气比较敏感，所以在矿场开工前工人们会放一只金丝雀进去，以验证矿场是否存在毒气，这便是金丝雀发布名称的由来。Next.js 在构建中加入金丝雀功能，然后称其为稳定版本，然后将其发送给所有用户，实际上就是将应用程序当成了试毒工具。可能你并不这么认为，也许这只是一个沟通的问题，但很多尝试过的人都告诉我，他们使用 Next.js App Router 的体验非常不理想，我认为这很大程度上是因为它的不完整性。这些功能只是金丝雀。
虽然有些人报告使用 App Router 的体验很好，但我相信他们的快乐很大程度上来自 pages 目录的瘦身，以及对嵌套路由功能的支持，这些不一定是金丝雀功能。
没错，React Server Components 非常酷，我期待在它们正式发布后使用。
太多魔法
你听说过最小惊讶原则吗？指的是：
系统组件的行为应符合大多数用户的预期，不应让用户感到惊讶或意外。
在 Web 平台下，避免让人们感到惊讶的最佳方法是尽可能遵循 Web 平台 API，并减少软件在平台的基础之上所施加的“魔法”量。魔法很好，可以减少样板文件等，但我必须能够有选择性地使用魔法，清楚发生了什么，而不是魔法自动生效。
Next.js在很多方面违反了这一原则。其中一个例子是覆写全局 fetch 函数，以添加自动缓存。对我来说，这是一个巨大的危险信号。正是这样的决定迫使我思考他们还有哪些动作，如果采用 Next.js，我还会遇到哪些“惊喜”。
经历过 MooTools 时代的大多数人都明白覆写平台的内置功能会引发各种问题（这就是我们使用String.prototype.includes 而不是 String.prototype.contains的原因）。这样做会对 Web 平台的未来产生负面影响，而且还意味着当调试为什么某些功能无法正常工作时，在网上搜索解答都必须搜索“ Next.js 版本的 fetch”而不是“ Web 平台的 fetch”。
复杂性
我收到很多人的反馈说，他们发现 Next.js 变得过于复杂。这也是“魔法太多”的因素之一。React 的server actions，以及新的实验性“污点”API，这些都是许多笑话的主题。
我非常看好 React 添加内置的 mutation 支持。但我非常担心它们会改变 Web 表单工作方式的语义。这种类似的功能都会增加复杂性。
Remix团队的领导对于许多原则的看法与我不谋而合，我感到非常欣喜，而且他们在添加类似的功能时，不会增加复杂性。事实上，Remix 团队一直在努力减少 API 的总量。
稳定性
目前 Next.js 的版本为 13。React Router（与 Remix 由同一团队构建）发布已经有很长一段时间了，目前只发布到了版本 6。Remix 的版本 1 发布已经近两年了，一个月前刚发布了版本 2。由于 Remix 团队对稳定性的重视，众人都知道这是该 Web 框架的主要版本升级。
今年早些时候，Remix 团队分享了他们的计划，他们打算使用一种名为“未来标志”的策略，将版本 2 的功能作为版本 1的、可选择的一部分发布。这个计划的效果非常好，大量积极开发的 Remix 应用在不到一天的时间内就升级了。
Remix团队非常关心稳定性。这就是为什么几年前尽管每个人都要求他们实现对 React Server 组件的支持，但他们依然没有跟风。这也是为什么 8 年来 React Router 只发生过一次重大变化的原因。
这种稳定性对我和我构建的应用程序产生了重大影响。我很害怕一些库升级，因为我曾有过花费数小时更新所有代码只为适应新版本的经历。Web 框架的影响力很大，因此我不希望再有类似的经历。而 Remix 在这方面为我提供了极大的安慰。
功能
你可能以为我会在本文中比较 Next.js 与 Remix 等其他框架的特性和功能。但我想指出的是，特性比功能更重要。我个人认为 Remix 比 Next.js 更成功。当然了，这些看法都很主观。
为了证明“Remix 与 Next.js 孰优孰劣”，Remix 团队重写了Next.js 的电子商务演示，并很好地证明了 Remix 用更少的代码带来了更好的用户体验。之后，Next.js 做了升级，转而使用 App Router（虽然他们称之为稳定版，但正如我在上面提到的那样依赖于金丝雀功能），因此我觉得应该重新比较一次。
总结
本文阐述的观点乃一家之言，你可能同意，也有可能不同意。总的来说，Next.js和Remix这两款框架的功能都很强大，但 Remix 在提高软件的可维护性和长期合作方面更符合我的期望。此外，Remix 积累的知识还可以转移到其他地方。
推荐阅读：
▶英伟达被曝开发 ARM 架构 PC 芯片，手握 x86 的英特尔坚称：ARM 对 PC 影响“微不足道”！
▶vivo 将发布全球首款基于 Rust 编写的操作系统；Windows 11 更新，含 AI 助手 Copilot｜极客头条