在选择 Next.js 之前，您应该了解这些信息

132 条评论 | |

为一个项目选择技术堆栈是一项重要且具有深远影响的决策。特别是在企业领域，这往往涉及到多年的承诺，对项目的路线图、开发速度、交付成果的质量，甚至是组建和维持一个快乐团队的能力都有长期的影响。

开源软件模式从根本上解决了这一问题。通过使用公开开发的软件，任何人都可以自由地对其进行扩展或修改，无论其使用方式如何。更重要的是，开源软件的可移植性为开发人员和组织提供了在不同供应商之间移动基础设施的自由，而不必担心被特定供应商锁定。

这就是对 Next.js 的期望。Next.js 是由 Vercel 创建和管理的开源网络开发框架，Vercel 是一家提供 Next.js 托管服务的云提供商。
公司从自己创建的开源软件中获利无可厚非，尤其是当这有助于为项目开发提供资金时。事实上，在我们的行业中，这种模式成功运作的例子比比皆是。

但我认为，只有公司和开源项目之间的界限非常清晰，维护者、托管服务提供商和用户之间对如何以及在何处使用框架的每项功能都有明确的预期，这种模式才能持续发挥作用。

我想解释一下为什么我认为现在不存在这种透明度。

我的目标不是阻止任何人使用 Next.js，而是尽可能多地提供信息，以便开发人员和企业能够就其技术栈做出明智的决定。

利益声明

让我先声明一下我的利益：

  • 我在 Netlify 工作，已经有四年多的时间
  • Netlify 是一个前端云平台，其产品支持 Next.js 和其他 Web 框架
  • Netlify 和 Vercel 是直接竞争对手

我必须声明这一点，原因有以下几点。

我的工作包括在 Netlify 上构建支持 Next.js 完整功能集所需的基础架构和工具，这让我以一种大多数人看不到的方式接触到了框架的内部结构。多年来，我看到了开源框架与构建该框架的公司的基础设施之间紧密耦合的相关模式。

我的工作也是我在公开场合表达这些担忧时总是非常谨慎的原因。作为 Netlify 的一名员工，我无法真正客观地表达对 Next.js 的担忧，而不会被人认为是 Netlify 释放其爪牙来散布对竞争对手的谣言。

我不想让自己和公司陷入这种争论，所以我一直选择在幕后工作，为决定在 Netlify 上部署网站的开发人员提供支持，让他们免受复杂性的影响。

但后来发生了一件事。

上周末，Vercel 披露了 Next.js 的一个重要安全漏洞。这类问题很正常，但 Vercel 选择的处理方式是如此糟糕、鲁莽和不尊重社区，这加剧了我对项目管理的担忧。

对我来说，一旦你的决定将其他人置于危险之中，情况就会发生变化，所以我觉得有说出来的冲动。

开放性和管理

我稍后会再谈这件事，但在此之前，我想先回过头来，让大家看一看幕后的故事。我一直对 Next.js 的开放性和治理持保留意见，这源于 Vercel 多年来做出的一系列决定，这些决定使得其他提供商在支持该框架的全部功能集时面临巨大挑战。

下面我将介绍一系列有关 Next.js 构建过程的事实。然后，我将补充一些自己的看法，说明这些事实如何不辜负人们对开放、可互操作的企业级软件产品的期望。

事实 #1：没有适配器

大多数现代 Web 开发框架都使用适配器的概念，将框架的输出配置为特定的部署目标： Remix, Astro, Nuxt, SvelteKit 和 Gatsby 只是其中的几个例子。这种模式允许开发人员保持其应用程序的核心不变，如果他们决定开始部署到不同的提供商，只需交换适配器即可。

这些适配器可以由框架作者、托管服务提供商、社区或上述各方共同维护。框架的结构通常是任何人都可以构建自己的适配器，以防自己选择的提供商没有适配器。

Next.js 没有适配器的概念，过去也曾表示不支持适配器。Next.js 构建的输出有一种专有的、未编入文档的格式，在 Vercel 部署中用于配置为应用程序提供动力所需的基础设施。

Vercel 的替代方案是 “构建输出 API”（Build Output API），它是针对希望部署到 Vercel 的框架的输出格式的文档规范。

这不是 Next.js 的适配器接口，事实上也与 Next.js 无关。公告博文中说 Next.js 支持这种格式，但从今天起事实并非如此。

2023 年 11 月，Next.js 文档更新称，Next.js 将在框架的下一个主要版本（即第 15 版）中采用构建输出 API：

Next.js 会生成一个标准的部署输出，供托管和自托管 Next.js 使用。这将确保两种部署方式都支持所有功能。在下一个主要版本中，我们将把这一输出转化为我们的构建输出 API 规范。

Next.js 15.0.0 于 2024 年 10 月发布，不支持构建输出 API。

Vercel 构建了构建输出 API，因为他们希望客户能够利用该领域丰富的框架生态系统，但他们自己的框架至今仍不支持该 API。

这意味着除 Vercel 之外的任何托管服务提供商都必须在无文档 API 的基础上进行构建，而这些 API 可能会在次版本或补丁版本中引入未经宣布的破坏性变更。(

去年年底，Cloudflare 和 Netlify 加入了 OpenNext，这是一个由不同云提供商组成的运动，他们合作开发 Next.js 的开源适配器。不久之后，Vercel 也加入了这一运动，并承诺为适配器提供支持。他们没有做出任何时间表承诺，但最近表示正在积极努力。

重要的是要记住，Build Output API 推出至今已有近三年时间，而框架至今仍未实现可移植性。我对这次的改变持谨慎乐观的态度。

事实二：官方不支持无服务器

官方自托管 Next.js 的方法要求以有状态的方式运行应用程序，即作为长期运行的服务器。虽然在技术上是可行的，但这很难在任何实际生产环境中运行，因为单个实例是不够的。

这种设置需要能够快速动态扩展，以处理突如其来的流量，同时也要能够向下扩展到零，以保证成本效益。例如，在处理服务器组件时，最后一部分是必不可少的，因为客户端和服务器代码之间的深度纠结可能会破坏旧版客户端，除非部署的每个版本的服务器代码都是无限期可用的。

满足这些要求的一个显而易见的答案就是无服务器计算，Next.js 的官方文档证实了这种模式的优势：

无服务器允许分布式故障点、无限的可扩展性，并且采用 “用多少付多少 “的模式，价格低廉得令人难以置信。

这种优势明显的计算模式正是 Vercel 多年来在自己的基础设施中运行 Next.js 网站的方式。鉴于 Next.js 是一个开放的框架，我们有理由相信，您可以在自己选择的任何无服务器提供商中使用相同的模式。但事实并非如此简单。

Next.js 曾经有一个无服务器模式，可以通过配置属性启用，但在 2022 年 10 月被移除，没有进一步解释。从未推出过同等模式。

Next.js 团队协助维护的 React 官方文档称，Next.js 可以部署到 “任何无服务器托管”，但并没有相关的官方文档。

这就意味着，如果任何提供商想使用与 Next.js 本身所倡导的计算模式相同的计算模式为 Next.js 提供支持，就必须逆向工程自定义实现。

事实 3：Vercel 专用代码路径

Next.js 有一些代码路径只在部署到 Vercel 的网站上执行。其中一个例子就是一个名为 minimal mode 的私有标志，它允许 Vercel 将工作从框架中转移出来，并在其边缘基础设施上运行。

下面的例子说明了这一点。Next 12 节介绍了中间件，这是解决功能标志、A/B 测试和高级路由等用例的一种方法。所有这些用例的共同点是需要在高速缓存后面的热路径上运行逻辑，并且延迟极低。

公告中包括了这一点：

这在使用下一步启动的开箱即用平台以及使用边缘中间件的边缘平台（如 Vercel）上均可实现。

在实践中，这意味着您有两种选择：使用 （next start）并在原始服务器中与应用程序的其余部分一起运行中间件（原始服务器通常在单个区域中运行，在缓存之后）；或者使用 “像 Vercel 这样的边缘平台”（Edge platforms like Vercel）之一，在缓存之前的边缘运行中间件，从而解锁 Vercel 在公告中链接的资源中吹嘘的所有令人难以置信的用例。

像 Vercel 这样的边缘平台 “这句话肯定意味着还有许多替代方案，因为其他供应商也可以选择在边缘实施中间件，对吗？不。

这种秘密的最小模式允许 Vercel 将中间件从应用程序的其他部分中分离出来，这样他们就可以在边缘运行中间件，但只有 Vercel 可以访问它。

Netlify 确实支持在边缘运行中间件，但我们为此付出的代价是组建了一个完整的工程师团队，专门负责对框架进行逆向工程，并在未注明的 API 基础上构建我们自己的边缘中间件实现。对于规模较小的公司来说，这种投入是不可能实现的，因为它们根本没有资源来打这场仗，这使得它们中的大多数都停止了尝试。

据我所知，除了 Vercel 之外，Netlify 是唯一一家支持 Next.js 完整功能集的云提供商，这在我看来毫无意义。由于 Next.js 在市场上占有如此大的份额，我希望有更多的托管选择，这将促进整个市场的竞争和创新，最终使用户和网络受益。

那么，Next.js 中为什么会有一扇只有 Vercel 才有钥匙的暗门呢？我认为，框架维护者在功能推出前定期进行实验是意料之中的事，但最小模式并非如此。我们现在讨论的是框架的一种完全不同的运行模式，这种模式在代码库中已经存在多年，它可以解锁为拥有框架的营利性公司保留的功能。

如果 WordPress 有一个特权代码路径，只有部署在 Automattic 属下的网站才能访问，那么它作为一个真正的开放项目还会受到信任吗？

安全态势

让我们回到安全事件上来。3 月 21 日星期五上午 10:17（世界协调时），Vercel 发布了一个严重安全事件的 CVE，严重程度为 9.1（满分 10 分）。

从本质上讲，任何人都有可能通过在请求中发送特定头完全绕过 Next.js 中间件。这一点非常重要，因为身份验证是中间件的主要用例之一，而这一漏洞意味着任何人都可以绕过身份验证层，访问受保护的资源。

随着事件的发展，有几件事变得显而易见。首先，该漏洞于 2 月 27 日报告给 Next.js 团队，但该团队直到 3 月 14 日才开始调查。一旦他们这样做了，他们就开始在几个小时内为 Next 14 和 Next 15 推送修复程序。

因此，到 3 月 14 日（最迟），Vercel 已经知道他们遇到了一起严重事故。此时，负责任的做法是立即向其他供应商披露该漏洞，以便他们评估该漏洞对自己客户的影响，并尽快采取必要行动保护客户。在这种时候，我们保护用户的责任应该高于公司之间的竞争。

但事实并非如此。Vercel 花了 8 天时间才与 Netlify 联系。在这段时间里，他们成功地向 Next.js 推送了补丁，删减了两个版本，甚至还写了一篇博文，把这次事件说成是 Vercel 的防火墙 “主动保护 ”了他们的客户（尽管他们的首席技术官后来说他们的防火墙与此事无关）。

我认为，把自己开源项目中的一个重要安全漏洞说成是自己产品的优势，完全不考虑其他供应商的用户是否也受到了影响，以及他们应该采取什么措施来减少影响，这是非常不诚实的。事实上，他们根本不知道这一点，因为此时他们甚至还没有联系我们。

在社交媒体上受到指责后，Vercel 重新撰写了博文，删除了任何有关其防火墙的内容，并澄清了哪些提供商受到了影响，以及他们的客户是否需要采取任何措施。

随后，Vercel 发布了一份事后报告，首次表示 3 月 21 日他们能够 “验证 Netlify 和 Cloudflare Workers 没有受到影响”。与此直接矛盾的是，他们的员工在 3 月 22 日联系 Netlify，表示愿意帮助 “打补丁”。如果我们没有受到影响，那还有什么需要打补丁的？

这种不考虑 Vercel 以外用户的做法给很多人带来了不必要的焦虑和困惑，导致一些提供商忙于寻找解决方案，然后不得不部分回滚，还有一些提供商宣布他们没有受到攻击，但实际上他们受到了攻击，等等。

当您读到这篇文章时，谁也不可能知道有多少网站仍然容易受到这个漏洞的攻击，如果以不同的方式处理，许多网站本来是安全的。

而在所有这些混乱的高峰期，Vercel 的领导层却……有不同的关注点。

但 Vercel 拥有 Next.js

没错 他们完全有权利将他们投入了大量的人力、才智、时间和精力来构建和发展的框架作为一项业务。我对此并无异议。

但在我看来，这种发展对他们提出了很高的标准，而他们却屡屡达不到。

“如果 Vercel 拥有 Next.js，那么他们有什么动力向其他供应商开放呢？”这是我有时会听到的一个问题，我觉得很有趣。如果 Redis 拥有 Redis Cloud，他们有什么动力开放自己的软件？既然 Grafana Cloud 属于同一家公司，为什么还要开放 Grafana 呢？还有 WordPress、ClickHouse 和其他许多公司？

他们的动机是，如果他们选择以开源方式发布软件，而不是封闭的专有解决方案，他们就必须做这些事情。他们的成功与他们的用户有内在联系，用户可以保证在任何时候自由选择任何提供服务的供应商，以满足他们的需求。

总结

说你应该使用哪个框架与我无关。如果你喜欢 Next.js，并且认为它是解决你所需问题的最佳工具，那么你绝对应该使用它。但无论你倾向于哪种方式，我都希望这些信息能帮助你对自己的决定更有信心。

至于我，我会继续做好我的工作，帮助支持那些选择将网站部署到 Netlify 的开发人员，无论他们选择的框架是什么。撇开竞争不谈，我真的很期待帮助 Vercel 通过 OpenNext 运动使 Next.js 更开放、更具互操作性。∎

¶Vercel 的回应

这是一个占位符，我将在这里分享我从 Vercel 收到的对这篇文章的任何回应。我尚未收到任何回复。如果您希望看到这些问题得到澄清，请考虑通过在社交媒体上分享本帖来征求 Vercel 的回应。

更新（3 月 26 日）：添加了关于 Vercel 最近尸检的说明和 Vercel 回应的部分。

你也许感兴趣的：

共有 132 条讨论

  1. 当 next.js 从页面路由器转向应用路由器时，我正在使用它。我最终放弃了这个项目，因为应用路由器的体验实在太糟糕了，从那以后我就再也没热衷于使用 next.js。

    很明显，Vercel 充其量只能算是开放源码软件。它既想声称自己是开源的，又想（有点偷偷摸摸地）建立一个围墙花园，将用户锁定在自己的托管平台上。

    回复

    1. 如果你正在使用 next.js，你并没有真正引入一个库/框架作为依赖关系–从技术上讲，你在产品中引入了一家咨询公司作为依赖关系。

      回复

    2. 我认为根本问题在于 next.js 试图同时做两件事。它希望 a) 快速加载对加载速度敏感的内容（搜索引擎优化内容、登陆页面、社交媒体可共享内容等）。它还希望支持复杂的客户端逻辑（单页应用程序、导航、状态存储等）。同时做到这两点真的很难。根据我的经验，这也是完全没有必要的。

      对于需要快速加载的内容，使用最小化的 html/css 和服务器端渲染（或许还有 CDN/边缘计算）。对于需要复杂功能的东西，使用 react/vue/ 其他重型框架。如果将它们分开，一切都会变得非常简单。如果将它们结合起来，推理就会变得非常困难。

      回复

      1. 这就是我的方法。我的网站 tyleo.com 就是一堆 CSS/HTML 经典网页。如果某个页面需要少量的 JS，我就会将其临时捆绑。更复杂的页面则采用 React/SPA 处理，但这并不意味着整个网站都需要这样。

        另外，我将 React 用作 HTML 的模板引擎，从而重复使用代码。每个页面基本上都有一个切换按钮，可以选择以动态模式还是静态模式发布，静态模式包括完整的 JS 捆绑包，动态模式则不包括任何内容。

        回复

      2. Sveltekit 在这方面表现出色。它比 vanilla 更简单/更容易，更不用说任何基于 React 的东西了。

        回复

    3. >next.js从页面路由器转为应用路由器时

      ，这简直就是react-router的翻版。对于那些不了解 React 的人来说，react-router 早在 React 诞生之初就出现了，很多人都在使用它。但是，他们每发布一个重要版本，就会彻底改变路由/路由的操作方式，因此如果你想使用已发布的版本，就必须不断重构，除了 “现在我们使用的是最新版本 “之外，往往没有任何实际收获。我就像使用 next.js 的父辈一样，最终因为太过繁琐而停止了使用。

      在我看来，程序员（尤其是类似库的程序员）在引入破坏性改动时没有更加谨慎，这有点奇怪，因为之后需要做的工作会成倍增加。我希望人们能把新东西分拆成新的库，而不是改变现有库的界面。

      回复

      1. 我喜欢使用 React Router 的 “新 “方法，它只是说 “大多数项目都是从模板开始的”……然后除了查看一个已经配置好的项目之外，没有给出将其添加到现有项目的安装说明：https://reactrouter.com/start/framework/installation

        回复

      2. 我有点不同意这个说法。是的，react-router 的很多改动都很麻烦，尤其是有些破坏性改动并不明显。但大部分改动都是语法上的，而且看起来合乎逻辑。

        对 react 的更大不满在于，一切都如此相互依赖，以至于像 react-dom 和 react-router 这样的东西还不如只是 react 的一部分–如果你更新了其中一个，无论如何都需要更新另一个。

        回复

        1. >是的，react-router的很多改动都很麻烦，尤其是有些破坏性改动并不明显。但大多数更改都是语法性的，而且看起来很合乎逻辑。

          “语法上的 “似乎加强了他的观点，不是吗？而不是功能性的。

          回复

          1. 我认为他的意图是：”让我们重构路由器的语法，这样我们就能添加更多的功能，而不会造成大麻烦”。至少在我看来是这样。

            回复

      3. 在使用 React Router 6.4 版本时，我曾为此感到不快，而在使用 7 版本时，当我看到库/框架被拆分时，我又再次感到不快，但在没有时间切换的情况下，我发现加载器、获取器、useMatches 和 BrowserRouters 这些东西正是我应该做的，它们符合人体工程学，而且非常有用。对它们进行调整正在推动我的应用向前发展。

        回复

      4. React-router 至今仍会导致奇怪的构建问题，尤其是 LLM 生成的代码无法理解版本兼容性。

        回复

        2. 如果你尝试构建不兼容的代码却无法运行，那就不是 bug

          回复

          1. 我认为，”核心 “react 库（DOM、react-router 等）之间的主要版本和次要版本之间存在太多不兼容的地方，而且这些团队在 API 表面以及如何将它们整合在一起方面有些鲁莽。

            说到底，这是一款自由软件，我也没有提交 PR 来改进它。更进一步说，react-router 可以在项目开始时设置，之后基本上就不会再碰了。这并不是世界末日，但它确实削减了很多刚接触 React、前端等软件的人的工作量，并给整个前端开发带来了巨大的成本。

            回复

            1. 我认为，你应该阅读文档并编写能正常工作的代码，这样就不会有任何问题了

              回复

      5. >我觉得有点奇怪的是，程序员（尤其是类似库的程序员）在引入破坏性改动时为什么不更加谨慎，因为之后需要做的工作会很快成倍增加。

        一般来说，程序员总是希望做到这一点。

        但 JS 框架世界不知出于什么原因，总是痴迷于重塑。老实说，我认为这源于 2000/10 年代 FE 开发人员的一种自卑感，这种自卑感导致每个库都觉得有必要发明一些新词来描述一些已经存在了 40 年的 CS 概念，并且为了听起来聪明而将事情过度复杂化。于是，存储变成了 “reducer”，承诺变成了 “thunks”，宏变成了 “runes”，许多 FE 开始自鸣得意，并将这些东西添加到他们的 FAANG 促销包中，而我们则沉湎于他们堆积如山的毫无意义的抽象概念中，以 “以正确的方式做事 “为名，就像 FB 和 Google 一样。

        回复

        1. >痴迷于重塑

          这似乎是以局外人的视角发表的评论。各种前端库不断更换 API，只是因为网络和相关技术在不断发展。

          变化速度最快的是什么时候？2010 年代，因为网络/应用程序的使用呈爆炸式增长，浏览器开始增加设计师和开发人员需要的功能。如果你的 CSS/UI 库不支持 CSS 网格，你会怎么做？这只是一种愚蠢的态度。

          >CS的概念已经存在了40年，为了让自己听起来更聪明，就把事情搞得过于复杂

          ，这也许是对的，但1）不只是FE的开发人员会这么做，2）这与我上面所说的实际原因是背道而驰的。

          回复

        2. >一般来说，程序员总是希望做到这一点

          根据几乎所有地方的流失量来看，我不同意大多数人似乎都希望做到这一点的说法。我在 Python、Rust、Ruby、Go 和其他一些语言中也遇到过类似的问题（跨多个版本）。不过，我将其他生态系统与 Clojure 进行了比较，Clojure 的目标其实是界面稳定性，因此这种比较可能并不公平。

          回复

        4. 不，这些术语并不是独一无二的新词。

          回复

    4. 时至今日，我仍然只使用页面。从长远来看，或者为了一个新项目，我想我得考虑一下 astro 或 vite/express

      回复

      2. 我使用 Vite，并建立了自己的路由器。效果很好，我可以用它做整个 SPA。

        回复

    5. 为什么应用程序路由器如此糟糕？

      回复

      1. 似乎付出与回报的比率很低。

        我仍有几个大型项目使用以前版本的 Next.js，我没有动力（经济上或其他方面）花费精力升级它们，原因无非是为了跟上最新版本。在我升级的一个项目中，我在解决奇怪的编译器错误方面遇到了很多麻烦，而且由于某些原因，编译时间明显缩短。

        回复

  2. 我一直对 Vercel 有点不放心，因为我曾尝试在 VPS 上自行托管 Next.js，结果遇到了他们设置的一些小陷阱，他们似乎想诱导你使用他们的平台托管。我知道他们总得支付账单，但长期寄希望于他们的善意确实有点冒险。

    他们处理这个漏洞的方式让我更加不安。

    Vercel 一开始把他们的防火墙说成是 “主动保护 “他们的客户，这无疑给人留下了不好的印象。

    这一点，再加上迟迟不通知其他平台，暴露了我之前没有考虑到的一个利益冲突问题：Vercel 是否因为可以在公开披露之前在自己的平台上推出缓解措施，然后说 “如果你使用我们的托管服务，就不会受到影响:)”，而降低了防止未来 Next.js 出现此类漏洞的积极性？

    回复

    1. 这让我想起了几年前（2014 年吧？）

      很多人都认为 Acquia 是由 Drupal 的创建者创办的，对开源项目有特殊的控制权，但归根结底，他们确实没有这种控制权。

      因此，当安全团队发现这个漏洞时，他们与尽可能多的 Drupal 托管平台进行了协调，在 CVE 公布之前，Pantheon、Platform.sh 和 Acquia 都立即在防火墙层面阻止了该漏洞的利用。

      回复

  3. 我警告大家远离 next.js。不出所料，V0 确实有机会大幅提高其采用率，因为人们并不了解它。

    对于选择 next.js，有哪些突出的反驳观点？我看到很多新开发人员不愿意考虑系统的部署和管理，这是一方面。如果你只知道 react，我想无需学习其他东西就能获得 SSR 是一种胜利，但代价是代码库的复杂性。

    还有其他问题吗？

    回复

    1. 多年来，我一直在使用 express 和 React 构建 SPA 应用程序。在最近的一个项目中，我们决定使用 Next.js 和自宿主。最大的好处是：1）中间件包含在同一个运行时中，因此无需为每个运行时设置多个项目和主机。我们只需构建一个 docker 镜像并将其放入 ECS。2）已经包含了路由、捆绑、过滤等功能。虽然有一些缺点，比如我宁愿使用开箱即用的 biome，也不愿使用 prettier/eslint，但大多数开发人员并不在意。

      从这个角度来看，我对它持保留意见，尤其是在最近的 CVE 之后。作为复杂性的一个例子，我必须设置 Sentry，虽然 Sentry 确实有一个专门针对 next.js 的软件包，但要确保我们在每一个可能的地方都能捕捉到具有适当上下文的错误仍然非常棘手。

      随着项目的成熟，我们可能会遇到一些障碍，让我们对使用 next.js 和自托管的决定产生怀疑，但总的来说，我们的开发团队使用它还是很有成效的。

      回复

    2. >选择 next.js 有哪些突出的反驳点？… 如果你只知道反应，我想无需学习其他东西就能获得 SSR，这是以代码库的复杂性为代价的胜利。

      除了 Next.js 之外，还有其他方法可以处理 SSR。比如 Remix。这是一个很受欢迎的软件。

      对于一个较小的项目，我不担心用 Vite 自己开发。它非常简单。

      对于任何开发人员，我都非常推荐使用 express 服务器或其他工具自行实现 SSR。它能真正加深你对框架工作原理的理解。

      回复

      1. Remix 不幸的是没有（内置的）静态导出。另外，Remix 现在更名为 “react-router”，这对他们的品牌并没有帮助。很多人不会把 react-router 与 SSR 框架联系起来。

        回复

    3. >我看到很多新开发人员不想考虑系统的部署和管理，这也是一个方面。

      也许人们应该重新发现在廉价主机上通过 FTP 传输文件的乐趣。

      大多数项目在这些主机上运行都不会有问题。如果是这样的话，只需一台裸机服务器+nginx就能实现扩展。

      回复

      1. 我专门建立了一个静态网站托管平台，目的是让人们重新找回在服务器上简单复制文件进行 “部署 ”的感觉

        https://pgs.sh

        回复

      2. > 也许人们应该重新发现在廉价主机上通过 FTP 传输文件的乐趣。

        问题是，我们之所以要摆脱这种模式，是因为应用程序开始被框架变得如此臃肿，以至于要花很长时间才能看到它们启动，因此必须使用大量的黑客手段才能让它们在合理的时间内做出响应，最终演变成像 Vercel 这样的服务，试图将黑客手段隐藏在 “上传即可 “的服务背后。

        因此，首先，人们必须重新发现不制造怪物的乐趣。但在有人可能会考虑 Nextjs 的时代…… 祝你好运

        回复

        1. 事实上，我正是这么做的，Next.js 确实支持静态导出。我用 React/TypeScript/Next.js 编写 SPA，然后导出为静态 html+js+css+assets。我只需将这些内容通过 sftp 传送到目标静态 webhost 即可。所有逻辑都在一个用 .NET/C# 编写的 REST 后端中。

          不幸的是，Next.js 每发布一个重要版本，都会回调对静态导出的支持，但它仍然可以通过静态导出创建 100% 的 SPA。

          回复

          1. > Next.js 确实支持静态导出。

            它最初不就是用来制作静态网站的吗？

            但是，伙计，在这一点上，你是在用推土机（操作台超级不舒服！）来打钉子。

            回复

            1. >但是，伙计，在这一点上，你是在用推土机（操作台超级不舒服！）来钉钉子。

              我想我的做法恰恰相反。没有 SSR 但所有东西都是静态导出的，这让我可以在后端使用更便宜的主机（REST API 位于便宜的 VPS 上）。静态导出 SPA 意味着，用户的浏览器可以完成所有繁重的渲染工作。此外，没有人工智能机器人或搜索引擎会增加我的服务器负载。

              此外，网站速度也很快。不知道你是否知道 Next.js 是如何工作的，但由于初始加载已经预渲染，而且只是静态 html+js，所以加载速度很快。然后在后台进行水合处理，用户不会注意到，而实际的 JS 会接管。在可能的情况下，JS+CSS 被分块，Nextjs 采用了一个巧妙的技巧：一旦鼠标悬停在链接上，无论是否点击，它都会为下一页预加载 js+css。这也提高了用户感知速度。此外，由于所有 js 块的文件名中都有其 sha1 hash，因此它们的缓存时间很长（甚至不可变，可永久缓存）–一旦你加载了网站，再次访问时速度会非常快。

              如果你想试试，网址是 https://lockmeout.online – 尽管我没有使用 CDN，而是将所有内容托管在廉价的 hetzner VPS 上 – 因此在欧洲以外的地区，加载时间可能会更长。

              回复

              1. >没有 SSR，但所有内容都是静态导出的，这让我可以在后台使用更便宜的主机

                建立一个静态网站是非常合理的。使用 Next.js 这个庞然大物来构建静态网站似乎有些矫枉过正，而且我也不确定它是否能给开发者带来良好的体验[1]。

                [1]我使用它的经验是需要动态驱动的页面，所以它的可怕设计可能只是在你超越静态页面生成时才会出现的问题。

                回复

                1. 你混淆了静态网站和静态导出的网络应用程序。我所做的网站并发布了链接，其中的用户/登录部分有很多交互功能。此外，它还有一些功能，如使用网络摄像头扫描 QR 码（使用 wasm 库在 JS 中从媒体流中读取 QR 码）、接收推送通知（在 iOS 上成为 PWA）、生成可定制的打印卡片等。

                  回复

    4. 正如在另一个回复中提到的，它被许多 SaaS 供应商视为其产品的唯一扩展框架。

      使用其他框架就意味着得不到支持，就意味着要花时间 “唠叨”，而不是编码真正的解决方案。

      从 Java/.NET 生态系统的角度来看，Next.js 是让我有家的感觉的框架。

      我与一些与 Vercel/Netlify 签订了合作伙伴协议的机构合作，这使得它成为 MACH 架构领域 SaaS 产品的一个不错选择。

      回复

    5. 路由的标准化是我的主要卖点。react-router 在大规模使用时就是一团糟

      回复

    6. 只要有关于路由的约定，以及 “just works “的构建& lint 就很好，可以避免团队自行修改自己的解决方案。(请不要推荐 react-router……它似乎每隔几年就会自我革新一次）。

      同一代码库中的 API 路由可以使用相同的 TypeScript 类型，而不是这些 typegen 工具，这也非常不错。

      我非常不喜欢摆弄构建、路由、水合、状态等工具，因为它们最终会让你分心，无法专注于你要做的事情。

      回复

    7. SSR 的必要性和实用性被夸大了。对于新项目来说，谷歌已经死了，如果一个人根据谷歌抓取的难易程度来优化自己的堆栈，我认为他们是在做一个没有回报的糟糕的架构决策。没有 Next.JS，部署 React/JavaScript 应用程序会容易得多。

      回复

      1. 我同意，但显然 Vercel 从选择 SSR 的团队中获益匪浅，因此团队需要谨慎对待。

        回复

  4. 我改用 next.js 的唯一原因是，在开发过程中，我在一个小项目上花了 6-7 秒才能在浏览器中看到我所做的更改（在一台 64GB 内存的 M1 Max Macbook pro 上）。这是在使用应用程序路由器的情况下，每次更改都需要一个编译步骤。

    现在我只使用带有 Vite 的 React SPA。

    回复

    1. 是的，这让我很震惊。我是一名后端开发人员，偶尔会修补前端。我试用了一下 nextjs，简直不敢相信新项目的重载时间。

      对于每天都使用它的人来说，这怎么能接受呢？

      回复

      1. 对我来说，这是可以接受的，因为我（和我团队中的其他人）几乎不需要花费 6-7 秒的时间，几乎是瞬间完成。偶尔会有一些变化需要很长时间才能显示出来，大约需要 5 秒，但似乎重启服务器就能解决这个问题，所以不知道是怎么回事。

        回复

        1. 你在 vercel 上使用过吗？

          在我参与的 NextJS 项目（本地运行）中，我也遇到过刷新缓慢的问题，其他经验丰富的 NextJS 开发人员认为这并不稀奇。

          回复

      2. >对于每天都使用它的人来说，如何/为什么可以接受这种情况？

        幸好我不用经常使用 Nextjs，一般来说，我甚至不确定自己是否每天都在浏览器中启动应用程序。你的测试和其他工作已经在持续反馈代码的状态了。偶尔 6-7 秒并不是世界末日。

        但即使是瞬时反馈，Nextjs 也会因为其他诸多原因给开发者带来糟糕的体验。

        回复

    2. >我现在只使用 Vite 的 React SPA。

      公平地说，听起来你一开始并不需要 Next.js？SPA 更像是一种替代而非模拟。

      不过 6-7s 的 HMR 太糟糕了。同意。

      回复

      1. 实际上，在某些情况下我也希望拥有 SSR，但对我的应用程序来说，拥有 SSR 并不重要。我只是觉得 Next.js（和 react）把 SSR 放在客户端渲染之上可以说是跳了槽。

        大多数网络应用需要的只是应用外壳的一个非常基本的 SSR 步骤，而不是所有东西都需要服务器端呈现，在需要服务器端呈现的情况下，我们已经有其他 SSR 优先框架解决了这个问题。

        回复

      2. Next.js 的主要功能是，你基本上可以获得 SPA 架构，但在首次加载时只需进行一次浏览器<->服务器往返，而不是两次往返。

        这就是 Next.js 复杂性的全部来源，而且因为这是一个很难解决的问题，所以它绝对值得赞赏。

        但如果你不需要，我就不明白你为什么要使用如此脆弱、复杂和试验性的东西。

        回复

        1. > 这就是 ~Next.js 所有复杂性的来源

          复杂性确实来自于此，但同样也来自于 Next.js 最终需要处理的 Vercel 服务的限制。一旦考虑到 Vercel（服务）对其施加的限制，Next.js 的许多看似愚蠢的设计决定就会变得合情合理，但它们仍然是你不得不接受的糟糕决定，而如果它打算运行在 “正常 “的计算环境中，这些决定是不必要的。

          回复

  6. 我对 Next.js 的看法不一。一方面，这是一家与投资者合作构建框架的公司，他们当然有动力占领市场。正如作者提到的，Redis labs 也有类似的模式。它的许可证是 MIT，所以 Netfify 或任何人都可以 fork 并提供更好的替代方案，只要他们有能力并愿意承担失败的风险。另外，如果我是 Vercel 的投资者，我为什么要鼓励他们通过帮助竞争来让我的投资面临风险呢？

    另一方面，Vercel 似乎也在耍花招。他们希望两全其美–既要成为一家支持和促进开源的公司，又要保持必要的摩擦，使自己的托管平台成为最佳选择。

    无论好坏，我认为这种模式在未来只会越来越多。

    回复

  7. 我目前正在为我工作的公司挑选 React 栈，我无法想象为什么有人会选择 Next.js，而不是其他替代方案。看起来，Next.js 只是 Vercel 的产品，是你想要远离而不是加入的东西。

    如果你想要 SSR 等，Remix（或 React Router v7，现在看来很混乱）甚至 TanStack（如果你对测试版有冒险精神的话）似乎都是更合理的选择。

    回复

  8. 我不太相信无服务器方法是一个好的默认设置。它增加了很多你可能根本不需要的复杂性。我也不喜欢在后台使用 Javascript，但这其实更多是个人偏好。但使用不同语言的后端是很常见的，所以在 React 的世界里，对服务器组件和 Next.js 的关注让我觉得有点像隧道视野。它所关注的用例与我的用例完全不同，这当然没有问题，因为并非所有功能都需要针对我的用例。但在我看来，将更狭窄、更专业的设置作为默认设置似乎是错误的选择。

    无服务器方法很可能是他们使用 HTTP 标头在应用程序各部分之间进行这种特权通信的原因。对于无法确保这些头不会被用户设置的环境来说，这是一个糟糕的主意。

    回复

  9. 更不用说绝对最糟糕的开发构建时间了，多年来有大量投诉的公开公关都没有得到解决。

    回复

  10. Vercel 和 NextJS 不应该存在。

    我曾经尝试过 NextJS，结果在生产中遇到了一堆水合错误。概念是好的，但这个框架只是为了在服务器上渲染的一些潜在好处而将一切都搞得过于复杂，而实际上这些都是不需要的（使用传统的 HTML 渲染即可）。

    我甚至还没提到这样一个事实，那就是整个框架都是为了推销他们高价的云服务而打造的一个漂亮门面，因为现在的开发人员无法编写一个 CI/CD 管道，将代码 rsyncs 到 VPS 并重新加载他们使用的任何反向代理。

    回复

  11. 我还记得自己尝试托管一个 Next.js Web 应用程序（没有 netlify 或 vercel），感觉非常麻烦。整个输出都不正常，就是不想启动。考虑到 Vercel

    回复

  12. 的拉动作用，我不认为它变得更好了。我确实喜欢一个自己做设计的网站。我们对 Medium 已经变得太懒惰了，很高兴看到有人能在展示方面找到乐趣。

    回复

  13. 远离任何与 Vercel 有关的东西

    回复

    1. 还有有影响力的 CEO，Vercel 是最主要的一个。

      回复

    2. 我不介意在他们的免费层上运行开源 js 应用程序：)

      回复

      1. 说到免费层，没有人比 Cloudflare 做得更好。

        回复

        1. 是的。我不得不回头检查一下为什么我更喜欢 vercel。原来它是一个 python 应用程序，而不是 js。

          回复

  15. 有趣的是，任何事物都会经历一个循环：它很神奇，它很糟糕，它很无聊

    回复

  16. 我没有用过最近的版本，但我记得 6 年前我曾在一个项目中尝试使用它，试图找出如何显示 SVG 的方法，这太荒谬了。解决方法是使用特定的 next-svg 软件包……但这并不是一个很好的经验，因为我们需要为普通用途找到特定的 Next 软件包。我们当时最终选择了 CRA，今天我想我们会选择 React/Vite，但我们也不需要 SSR 为项目带来任何好处

    回复

  17. 我觉得开源真正的最佳状态是由爱好者/业余爱好者完成的，而不一定是由公司完成的。React 和 Nextjs 在我看来总是有点可疑，而 Svelte 和 Vue 则不然。

    实际上，PG 有一篇关于 Java 的旧文，我觉得他说的很多话都适用于 Nextjs：https://www.paulgraham.com/javacover.html

    回复

    1. >而 Svelte 和 Vue 则不然。

      Svelte 的负责人几年前受雇于 Vercel，现在已经完全融入其中。他们采用了与 React 相同的策略。

      回复

      1. 我不能代表 Rich Harris 发言，但 Svelte 和 Sveltekit 从未作为任何公司的一部分创建。这些工具是有机创建的。

        据我所知，里奇只是 Vercel 的一名员工，他们付给他全职工作的报酬。尽管如此，我相信 Svelte 的目标仍然是保持独立。我猜想 Vercel 只是想让他在公司内部工作，这样他们就能关注 js 框架领域的最新发展。

        回复

  18. 我一直对 VERCEL 抱有很大的怀疑，尽管或者也可能是因为我非常喜欢他们的设计和对公众的吸引力。但他们所做所谈的一切都让我感到毛骨悚然，有什么东西在告诉我，他们并不真诚，并在保留什么东西。也许就像你和一个非常讨人喜欢的人交谈时的感觉一样，你知道他是个神经病，让你脖子上的毛都竖起来了。

    当他们无法决定边缘功能战略，发表了一些毫无意义或部分有意义但显然不是全貌的声明时，这种感觉可能是最强烈的。

    购买 rich Harris，同时又保证这不会对 Sveltekit 的锁定水平产生影响，这让我感到非常焦虑。到目前为止，我还没有看到 sveltekit 出现任何具体的问题，但很难想象这种情况不会发生。希望 rich 能保持自己的诚信和觉悟，在适当的时候离开。

    回复

    1. 我发现问题在于，Vercel 有很好的产品愿景，但在工程部门却很薄弱，所以遇到的情况最终都会陷入某种不可思议的谷底。

      回复

      1. 我认为问题恰恰相反。首席技术官之前的职责是负责谷歌的搜索体验。

        回复

        1. >我认为这恰恰相反。

          除了 “诉诸权威 “之外，你还能从哪些方面看出他们在工程技术方面很强？

          >首席技术官之前的职务是负责谷歌的搜索体验。

          谷歌搜索也有很好的产品愿景，但工程执行不力，这听起来差不多。我不知道有多少次听到有人说，他们想使用谷歌搜索，但却不得不使用一些愚蠢的黑客手段，比如添加 “site:reddit.com”，这样才能得到有用的信息。

          不过，为了公平起见，他只在 “桌面谷歌搜索 “上下功夫，而 “桌面谷歌搜索 “可能并不是搜索结果部门。一个文本输入框和两个按钮确实保持居中。有人说这是工程学中最难的问题，但我敢肯定他们是在开玩笑。

          回复

  19. 如果我想坚持使用 React，有什么好的替代方案吗？还有其他框架支持服务器/客户端混合渲染吗？

    回复

    1. 我最近在试用 Astro。看起来不错。它允许你引入任何类型的组件： React、Svelte 等。虽然也有不足之处，但都是一样的东西，只是方法略有不同。

      但无论如何，我认为有很多替代方案。Next.JS 只是吸引了大家的注意力，让人觉得没有其他工具能与之媲美。

      回复

    2. 我认为目前有三种不错的替代方案： – Astro – React Router 7（前 Remix） – Tanstack Start

      Astro 更侧重于基于内容的网站，而其他两个也可用于 Web 应用程序。

      回复

    3. 有很多 Astro 推荐。我也喜欢它，但只适用于内容较多的网站。根据我的经验，如果你不具备这种条件，它就不如 Remix 那样容易使用。

      回复

        1. >这是一个常见的误解。

          我觉得这让我听起来像是在重复我听说过的事情。这是我的经验，而不是我先入为主的观念。我发现使用 Next.js、Remix 等（如果我们要比较框架的话）比 Astro 更容易实现动态 Web 应用程序。

          如果有人喜欢用 Astro 构建实质性的动态 SPA，我会感到非常惊讶。但如果你就是这样的人，我很乐意听到更多。

          回复

          1. 我之所以这么说，是因为人们很容易误以为 Astro 只是那些博客预渲染引擎之一，因为它默认情况下会剥离 JavaScript，并具有 Collections API 和内置标记符渲染等功能。但我也愿意说，Astro并不比Next.js或Remix难，只是采用了不同的方法（孤岛）。

            实际上，我曾用 Astro[0] 构建过一个大型动态 SPA，如果可以重来一次，我还是会选择 Astro，因为 Astro 和其他框架一样，对数据获取有很好的支持，而且还能让应用程序的某些部分完全不需要 JavaScript，比如登录页面，只需要浏览器原生表单就足够了。

            [0]: https://github.com/mayo-dayo/app

            回复

            1. 非常酷，感谢您的分享。我会去看看的。

              我同意它不能只用于博客和静态网站。我发现它在其他情况下比较难用，不过我会在那个软件仓库里找找看。

              回复

    4. 我非常喜欢 ReactRouter v7（它的前身是 Remix）。

      回复

    5. 我不使用 SSR，但对 SolidJs 非常满意

      回复

  20. > 由于 Next.js 在市场上占有如此大的份额，我希望有更多的托管选择，这将促进整个市场的竞争和创新，最终使用户和网络受益。

    会这样吗？还是会把 Next.js 托管变成边际利润为零的商品，最终导致无法为开发提供资金？

    回复

    1. WordPress 虽然目前闹得沸沸扬扬，但它是一个开源项目的典范，有许多不同的竞争者，开发工作似乎进展顺利。

      文章中提到的人为制造护城河和虚报功能的做法可能会给 Vercel 带来价值，但却会伤害消费者的信心。由于这种锁定，我不会也没有选择 Next 来做项目。

      回复

  21. 正是因为有了这样的文章，我才无法理解那些在谈论 React Native 时说’换成 Expo 就好了’的人。前端应该是各种解决方案的拼图，而不是少数几家公司为了摆脱问题而出售’妙语’的铁板一块。

    回复

  22. 如果你想知道是否应该证明正文的合理性，答案通常是否定的，尤其是在网络上。

    回复

  23. 作为一名帮助选择堆栈项目的架构师，这篇文章和这个主题大声疾呼不要使用 next.js。

    在研究技术堆栈时，审查奥斯维护者是我首先要完成的任务之一。

    哪怕是最轻微的道德顾虑，都会让我在做决定时排除在外。

    回复

  24. 除此之外，在最近几个版本中，Next.js 在静态构建导出（所有内容都被编译并导出为静态 html+js+assets，然后放入 out/）方面变得更糟–这似乎不再是优先事项。

    他们的内置图片导出器（next/image）从未支持过静态导出（与 gatsby 相反）。前段时间，当我在 HackerNews 上提到这一点时，Vercel 的一名员工试图反驳并否认他其实是 Vercel 的员工[0]。

    总之，这家公司的商业行为很粗略。

    [0]: https://news.ycombinator.com/item?id=43051961#43056980

    回复

    1. next/image 在我看来是 NextJS 的一个特别糟糕的组件。

      至少在我上次使用它的时候（大约一年前），它对基本图像转换的支持非常少。例如，图像的大小调整和裁剪总是忽略所提供的高度，而按照要求的宽度调整大小。对长宽比的任何改变都是通过 div 封装和 CSS 来完成的，图片本身实际上并没有按照要求的长宽比进行裁剪。

      我的抱怨并不是针对 Next，因为很多图片服务都会这样做，但我一直不喜欢图片服务返回的图片格式与要求的不同。决定请求何种图片文件大小和格式是浏览器的事，后端应该只提供请求的内容，而不是根据请求头来巧妙地决定 “最佳 “格式。

      回复

  25. Next.js 暗地里是一个付费框架，设计用于在 Vercel 上运行，伪装成开源的样子，不知何故，连最受欢迎的 YouTuber 都在继续为他们吹嘘这是 “最好的 “框架。

    回复

  26. 我完全不理解这样的做法。任何技术的扩展都会遇到瓶颈。Shopify 在 Rails 上建立了一个帝国，这个框架经常因为可扩展性问题而受到批评，但他们却因为知道如何利用其局限性而蓬勃发展。优秀的工程团队能将瓶颈转化为已解决的问题，而不是破坏者。

    回复

  27. 离题了，但 “Build Times “是一个很好的博客名字。

    回复

  28. 在我的印象中，Next.js 是 React 的后继者？是不是这样？

    回复

    1. 我完全理解你的想法。背景：

      create-react 是 React 的启动模板，由 Facebook 构建和维护。[1]

      ，该项目已被弃用，而用于 react 项目的 Next.js 站点框架大受欢迎（当然我也认为 Vercel 进行了大量游说），促使 react 文档正式建议将 create-next 作为新的起点。[2]

      注意，还有很多其他方法可以启动 react 项目，也有很多 react 项目不使用或不需要 Nextjs。(例如，我经常使用 react，但我将它与 Astro.js 搭配使用。）

      ，我认为一个轻量级的 Vite 模板就足以让你在使用 React 学习/构建本地环境的初期取得成功。

      [1] https://github.com/facebook/create-react-app [2] https://react.dev/learn/creating-a-react-app

      回复

      1. >该项目已被弃用，而用于 react 项目的 Next.js 站点框架大受欢迎（我当然还假定 Vercel 进行了大力游说），促使 react 文档正式建议将 create-next 作为新的起点。

        看起来，Vercel 有足够的资金和炒作来吸引 react 开发人员离开 facebook，为他们工作。我认为这是 react 将用户推向 Vercel 的最大原因。此外，在开发 react 服务器组件时，Vercel 能够与 react 开发团队紧密合作，这让 vercel 在率先进入市场方面具有优势，并在锁定供应商方面占得先机。

        回复

      2. 是的，这就是我所记得的。很高兴看到我没有把 “create-next “当成创建 React 网站的起点。

        回复

      3. >该项目已被贬值，而 Next.js 网站框架在 React 项目中的流行（我当然还假定 Vercel 进行了大量游说）促使 react 文档正式建议将 create-next 作为新的起点。[2]

        这是一个非常慷慨的说法。

        回复

    2. 不，React 纯粹是一个在屏幕上呈现 HTML 元素的库。NextJS 也使用 React，但它更全面。例如，它提供了开箱即用的路由、服务器端/客户端渲染位，而且可以将你的代码作为网络应用程序运行。

      回复

    3. >在我的印象中，Next.js 是 React 的后继者？不是这样吗？

      你也许应该先读读这篇文章再发帖。

      回复

      1. 抱歉，我的问题用词不当。我应该问 “是不是这样？

        在我的记忆中，hello world “入门 “项目是要在某个时候创建一个 “Next.js “应用程序。现在我看到，他们在 https://react.dev/blog/2025/02/14/sunsetting-create-react-ap… 记录了他们并不推荐任何 “入门 “路径。这让我有些意外，但也谈不上震惊。

        回复

    4. 你并没有完全错。React 由 Meta 和 Vercel 维护。React 目前也存在服务器优先和客户端优先的分歧，就像 Python 2 和 Python 3 一样。Next.js 是实现服务器优先的 React 的 “官方 “方法。

      回复

    5. Next.js 是基于 React UI 库构建的框架。

      与基于 Svelte 构建的 SvelteKit 和基于 Vue 构建的 Nuxt 类似。

      回复

    6. 不知道你为什么灰心丧气，因为当我在研究我的前端平台选择时，“宇宙 ”似乎就是这样定格的。当时的框架是，你似乎要么使用 next.js，要么用无聊的老式 react 编写某种 “传统应用程序”。事实证明并非如此。

      我不需要 SSR，而且我的研究表明 next.js 可能会矫枉过正，所以我选择了 react + vite。到目前为止一切顺利。

      回复

    7. 并非如此。Next.js 仍然是 React。它更像是 React 的一个包装/辅助车/框架，在如何构建应用方面引入了一些观点，并在你购买的情况下提供了一些好处。

      回复

    8. 算是吧。Vercel 找到了一种破坏 React 的方法，从而为自己带来利益和利润。

      回复

  29. 我之所以选择 Next.js，是因为它是许多 SaaS 供应商完全支持的官方框架，这要归功于合作伙伴协议，而且在使用其他框架时，我不喜欢自己做支持工作。

    回复

  30. Well shoot. 我至少一周前才开始了一个新的 Next.js 项目。大家的替代方案是什么？

    回复

    1. PHP 和 Laravel（免费的入门套件，稳定。）

      Python 和 Django（SaaS Pegasus 是一个很好的付费模板，配有独立的 React 前端示例。）

      回复

    2. 只使用 React 和任何后端？

      如果你有时间做这个项目，你就有时间学习过去 15 多年来每家公司都在使用的正确设置。

      坦率地说，如果你在 CDN 上分发前端，SSR 就是一个性能神话。归根结底，你的云计算功能要与位于中心位置的数据库相连…… 大多数情况下，没有 SSR，搜索引擎优化也能很好地运行。

      回复

      1. 在我看来，SSR 完全被夸大了，而且给你的项目增加了大量复杂性。反正所有这些搜索索引器都在运行无头 Chrome 浏览器，所以搜索引擎优化的说法现在基本上是错误的。

        在我看来，运行 vite 并部署一个与 API 交互的完全静态网站，要比在一个黑盒子渲染库（react）之上运行一个黑盒子反应框架（next.js）简单得多。

        对于大多数项目来说，“为前端设计一个后台 ”纯粹是一种开销。我在 FE 上开发了十年，只需要过一次 SSR，当然也从未需要过什么静态/动态/孤岛混合设置。

        如果你需要 SSR，你就需要它，但我发现 SPA 在开发速度和应用程序加载 JS 后的整体性能方面要优越得多。

        回复

      2. >最终，您的云功能会连接到位于中心位置的数据库…

        一个很大的区别是，在数据中心运行的代码应始终与网络保持良好连接。而在移动网络覆盖边缘徘徊的用户运行代码时… 就没那么简单了。SSR 意味着用户可以在一次往返后开始使用，而不是至少两次（更现实的是至少三次–HTML、JavaScript 和数据），随着延迟的增加，这一点变得非常重要。

        不过我也同意，真正需要这样做的情况并不像我们想象的那样常见，而且即使在合理的情况下，很多开发人员也会把事情搞砸，导致应用程序在没有多次往返的情况下无法使用。这当然是您应该深思熟虑的问题。这并不是无代价的。

        回复

  31. >自托管 Next.js 的官方方法要求以有状态的方式运行应用程序，将其作为长期运行的服务器。虽然在技术上是可行的，但在任何实际生产环境中都很难实现，因为单个实例是不够的。

    拜托，这明显是错误的说法。

    Next.js的部署本质上并不存在状态问题，自托管也有详尽的文档说明，而且简单明了：https://nextjs.org/docs/pages/building-your-application/depl…

    如果你使用过任何现代部署管道，你就会知道自托管 Next.js 不会比任何其他 React 应用程序更复杂。您可以通过标准实践来构建、部署和扩展它。

    对于许多拥有现有基础设施的团队来说，自托管实际上比迁移到 Vercel 这样的平台更简单。>设置需要能够快速动态扩展，以处理突如其来的流量，同时又要能够缩减到零，这样才能符合成本效益。

    对于绝大多数已部署的应用程序来说，这显然不是问题，因为即使是单个 nextjs 实例也能轻松处理每秒数千次的请求。

    回复

  32. 如果你真的遇到了它能很好解决的问题（SSR 和后端代理），Next 就是一个绝佳的选择。如果没有，它就是一个臃肿的大杂烩，你应该坚持使用传统的 SPA。

    回复

  33. 远离 Vercel 和 Netlify。

    两者都是炒作技术，会走 Gastby 的老路。

    回复

  34. 很高兴看到有人愿意把自己的头伸出战壕墙外。我曾在 “Vercel 克隆版 “上工作过一年。有了那次经历，我也会警告朋友们远离 Next.js。话虽如此，我们并不欠 Vercel 任何东西，如果他们想推出一个本质上是其服务加密狗的框架，他们完全有权这么做。

    回复

    1. 是的，他们可以推出这样的加密狗，但他们无权声称自己是开源的，也无权倾听用户的声音。问题在于该公司的虚伪，因此也就失去了信任。

      回复

  35. 我一直在构建一个完全开源的平台，用于托管自己的复杂网络应用程序。

    我最近刚刚开源了 JS 框架。它可以根据你的需要按需加载模块。它应该是 React+Redux、Angular 等的全能替代品。

    https://github.com/Qbix/Q.js

    欢迎反馈。我确实想开始推广它，但现在还为时尚早。

    编辑：为什么有这么多的降权，却没有任何反馈？只是好奇。难道投票者希望我不与他人分享我的 MIT 许可开源代码？他们希望人们只了解现有的加密者？

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注