【外评】不只是你，Next.js 也越来越难用了

171 条评论 | |

前几天我写了一篇博文，谈到 Next.js 中间件如何有助于绕过服务器组件施加的某些限制。这引起了一些有趣的讨论，比如这是否是一种合理的方法，或者 Next.js DX 是否只是……糟糕。

在我看来，Next.js 的应用程序路由器有两大问题，使其难以被采用：

  • 你需要了解很多内部知识才能完成看似基本的任务。
  • 有很多方法可以让你选择退出而不是选择加入。

为了更好地理解这一点，让我们来看看它的前身 Pages Router。

快速了解 Pages Router

当我第一次了解 Next.js 时，主要的 “竞争对手 “是 Create React App（CRA）。我的所有项目都在使用 CRA，但出于两个原因，我改用了 Next.js：

  • 我喜欢基于 file 的路由，因为它允许我编写更少的模板代码。
  • 每当我运行开发服务器时，CRA 都会打开 http://localhost:3000（这很快就会变得很烦人），而 Next.js 不会。

第二个原因可能有点傻，但对我来说，Next.js 就是这样：

具有更好默认设置的 React。

这就是我真正想要的。直到后来，我才发现 Next.js 的其他功能。API routes 让我兴奋不已，因为它让我无需设置任何额外的基础设施就能实现无服务器功能–这对于营销网站上的 “联系我们 “表单之类的东西来说超级方便。

这些概念很强大，但也很简单。

API 路由的外观和行为与其他路由处理程序非常相似。getServerSideProps 有点不同，但一旦你理解了如何获取请求和响应格式，它就会变得非常简单。

App Router 发布

Next 13 版本引入了 App Router，增加了许多新功能。服务器组件（Server Components）可以让你在服务器上呈现 React 组件，减少发送到客户端的数据量。

有了布局（Layouts），您就可以定义多个路由共享的用户界面，而无需在每次导航时重新渲染。

缓存变得……更加复杂。

虽然这些功能都很有趣，但最大的损失是简单性。

当框架做不到你想象的那样时

作为开发人员，一个相当普遍的经历就是用头撞墙，然后大喊：”为什么这个不能用？

每个人都有这样的经历，而且总是很糟糕。对我来说，如果感觉这不是代码中的错误，而是对事情应该如何工作的误解，那就更痛苦了。

你不再大喊：”为什么这个不起作用？”而是大喊：”为什么这个……会这样起作用？”

不幸的是，App Router 充满了这类微妙之处。

让我们回顾一下我最初的问题：我只想在服务器组件中获取 URL。下面是 Github 上一个热门问题的答案，我将在这里发布其中的一部分：

退一步说，”为什么我不能访问路径名或当前 URL？”这个问题是一个更大问题的一部分：”为什么我不能访问完整的请求和响应对象？

Next.js 既是一个静态呈现框架，也是一个动态呈现框架，它将工作分割成路由段。虽然公开请求/响应非常强大，但这些对象本质上是动态的，会影响整个路由。这就限制了该框架实现当前（缓存和流）和未来（部分预渲染）优化的能力。

为了应对这一挑战，我们考虑过公开请求对象并跟踪其访问位置（例如使用代理）。但这将使跟踪代码库中如何使用这些方法变得更加困难，并可能导致开发人员无意中选择动态呈现。

相反，我们暴露了 Web Request API 中的特定方法，统一并优化了每种方法在不同上下文中的使用：组件、服务器操作、路由处理程序和中间件。这些 API 允许开发人员明确选择动态呈现等框架启发式方法，并使 Next.js 更容易跟踪使用情况、分解工作并尽可能优化。

例如，在使用标头时，框架知道要选择动态呈现来处理请求。或者，就 Cookie 而言，你可以在 React 渲染上下文中读取 Cookie，但只能在突变上下文（如服务器操作和路由处理程序）中设置 Cookie，因为一旦流媒体开始，就无法设置 Cookie。

不管怎么说，这篇回应都是令人难以置信的。它写得很好，帮助我理解了很多基本问题，让我深入了解了与不同方法相关的权衡，而这些是我完全没有想到的。

话虽如此，如果你是一名开发人员，而你所要做的只是在服务器组件中获取 URL，那么你可能在读完这篇文章后，还要再 Google 5 次，然后才会意识到你可能必须重组你的代码。

这篇文章总结了我的感受：

这并不是说它一定不正确，而是出乎意料。

原帖还提到了其他一些微妙之处。其中一个常见的问题是如何处理 cookie。你可以在任何地方调用 cookies().set("key", "value")，它会进行类型检查，但在某些情况下，它会在运行时失败。

与 “旧 “的处理方式相比，在 “旧 “的处理方式中，你可以得到一个大的请求对象，并可以在服务器上做任何你想做的事情，可以说复杂性有了很大的提高。

我还需要指出的是，”默认开启 “的激进缓存是一种粗糙的体验。我认为，更多的人希望选择加入缓存，而不是翻阅大量文档来了解如何退出缓存。

我相信其他公司也遇到过类似的问题，但在 PropelAuth，我们经常收到一些错误报告，这些报告并不是错误，而是 “你以为你进行了 API 调用，但其实没有，你只是在读取缓存结果”。

所有这些都引出了一个问题：这些功能和优化是为谁准备的？

很难打造一个放之四海而皆准的产品

我所说的这些过于复杂的功能对某些人来说确实很重要。例如，如果您正在构建一个电子商务平台，这里就有一些很棒的功能。

网页加载速度更快，因为发送到客户端的数据更少。页面加载速度更快，因为所有内容都被积极缓存。页面加载速度更快，因为当用户浏览新页面时，只有部分页面需要重新渲染。而在电子商务领域，更快的页面加载速度意味着更多的利润，因此你绝对会为它们选择一个更复杂的框架。

但如果我正在为我的 SaaS 应用程序构建一个仪表盘……我并不关心这些。我更关心的是功能发布的速度，而所有这些复杂性都会成为我的开发团队的负担。

我个人在 App Router 上的经验和挫折会与其他人不同，因为我们的产品不同、用例不同、资源也不同。作为一个花大量时间编写并帮助他人编写 B2B SaaS 应用程序的人来说，App Router DX 比 Pages Router 差了一大步。

随着框架的发展，这是不可避免的吗？

随着产品/框架的发展，它们往往会变得更加复杂。客户会提出更多要求。大客户要求的东西更具体。大客户需要支付更多费用，因此你需要优先考虑并构建这些更具体的东西。

以前喜欢简单的客户会因为感觉事情复杂而恼火，然后……哦，看啊，又出现了一个更简单的新框架。我们都应该改用它！

要避免这种情况是很有挑战性的，但减少这种情况的方法之一就是不要让每个人都去处理只有某些人才需要的复杂问题。

推荐的东西并不意味着适合你

App Router 给我带来的最大问题之一就是这个：

在 App Router 正式投入生产使用之前，Next.js 就已经正式建议您使用它。对于 TypeScript、ESLint 或 Tailwind 是否适合你的项目，Next.js 并没有给出建议（尽管对 TS/ESLint 的默认设置是 “是”，对 Tailwind 的默认设置是 “否”–抱歉 Tailwind 的粉丝们），但它绝对相信你应该使用 App Router。

React 官方文档并不赞同这种观点。他们目前推荐使用 Pages Router，并将 App Router 描述为 “Bleeding-edge React Framework”。

从这个角度来看 App Router，它就更有意义了。与其将其视为 React 的推荐默认设置，不如将其视为测试版。它的体验更加复杂，一些原本简单的事情现在变得困难/不可能，但对于仍处于 “前沿 “的东西，你还能期待什么呢？

因此，当你为下一个项目选择框架时，应该认识到 App Router 仍有许多粗糙的边缘。您可能会选择更适合您使用情况的其他工具。

本文文字及图片出自 It’s not just you, Next.js is getting harder to use

你也许感兴趣的：

共有 171 条讨论

  1. 我们在试用了 4 个月的新应用程序后，刚刚从 Nextjs 转回。

    我们遇到了一些问题：

    – 开发环境过于复杂。重载全页面而不是 HMR，重载 x 次后会出现随机错误。

    – 缓存是个黑洞，开发环境和生产环境的缓存效果不同。现在他们正在用 v15 版改变现状，但这种缺乏稳定性的情况并不好。

    – 基于文件的路由器有其局限性。例如：在 URL 中设置语言意味着当语言发生变化时，整个树都会重新挂载。

    – 没有明确的方法在 React 之外引导特定内容

    – 门户网站似乎无法在服务器上运行。

    – 很容易弄乱 auth 东西。Supabase 甚至在 YT 上发布了一段视频[0]，视频中他们的实现导致 auth 意外缓存。为了安全起见，您需要进行三层检查，但这一切都很不透明。

    对我来说，如何将客户端和服务器状态结合起来也不清楚。这些模式尚未定义，我不断遇到水合问题，却没有明确的解决方案。

    在App Router推出一年后，我仍然感觉生态环境非常脆弱。

    我还用 Next 替代了 Gatsby 的 SSR，但很快就发现 Next 无法像 Gatsby 那样轻松预生成静态输出所需的所有响应图片尺寸。你需要实现一个自定义加载器，并依赖云端程序（cloudinary）之类的东西。这对于一个完全静态的网站来说实在是太荒谬了。

    [0] https://youtu.be/v6UvgfSIjQ0

    回复
    1.   - very easy to mess up auth stuff. At some point Supabase even put out a YT    
  video [0] where their implementation caused auth to be accidentally cached. There 
  are 3 levels of checks you need to do just to be safe, but this is all very opaque.

      Auth 是您所需要的一切。这是一个非功能性的要求，因为如果Auth 失效，你的网站就无法运行。

      在大型网站上，雅虎、谷歌或 Facebook 会收购一个网站，并将其连接到自己的整个服务中；但在小型网站上，”我需要一个电子邮件通讯脚本”，我不需要去搞什么 HMR、基于文件的路由和其他不重要的东西来开发我自己的脚本，我只需要选择一个最好的应用程序，并将其连接到我的用户数据库和认证系统，然后我就可以开展业务了。(如今，如果没有简洁的应用程序接口（API），我可以黑进该应用程序来查询我的用户数据库，如果技术栈与我的技术栈足够相似，我还可以黑进我的授权模块，但我要冒冒风险，克服该路由所带来的各种不便）。

      回复

      1. 在应用程序安全方面，滚动自己的验证模块是第一大禁忌。除非你是专家，否则还是留给专家去做吧

        回复

        1. 绝对不同意。你不应该自己开发 bcrypt，但你应该充分了解如何使用它来提供身份验证。在许多企业软件的销售过程中，这都是必不可少的。如果你不知道密码是如何工作的，看在上帝的份上，就不要提供基于密码的登录。

          回复

        2. 没错。对我来说，最重要的不是验证模块的实现，而是它与系统其他部分连接的应用程序接口。我想要的是专家设计的模块，我可以将各种系统接入其中。

          因为我们还没有看到用户管理层面的良好框架，所以我认为，YT 视频创作者所犯的错误在业内很常见。

          回复

          1. 请深思熟虑地提出你的实质性观点，不要进行人身攻击。对于本网站来说，”你他妈在说什么 “的攻击性太强了，如果你查看一下指导原则，就会发现这一点。

            即使是 “很抱歉，但是”，也是我们在这里极力避免的谩骂。

            如果您不介意重温一下 https://news.ycombinator.com/newsguidelines.html，并更加重视本网站的精神，我们将不胜感激。

            编辑：不幸的是，你最近经常这样做：

            https://news.ycombinator.com/item?id=40819104

            https://news.ycombinator.com/item?id=40818298

            https://news.ycombinator.com/item?id=40817238

            https://news.ycombinator.com/item?id=40810372

            我们必须封禁这样发帖的账户，所以如果你们能解决这个问题就好了。

            回复

          2. 不实施认证并不意味着使用平台。只需使用众多 OIDC 客户端/服务器库或完全预制的开源 docker 化服务即可。

            例如，在客户端使用 react-oidc-context，在服务器端使用 Passport.js，或者 Casdoor。

            回复

            1. 无论作为用户还是消费者，只要你的认证提供商倒闭一次，你就会完全放弃这个想法。

              编辑：Docker 化服务听起来很有趣，你有例子吗？

              回复

              1. Casdoor 就是这样一种 Docker 映像，或者 Authelia、FusionAuth、Authentik 或 Ory 栈也是如此。

                回复

          3. 对不起，加密并不难。登录并不难。会话管理也不难。

            验证你是否违反了这些规定很难，而在有大量合法用户的情况下监控违规行为则非常困难。

            回复

            1. 验证你的供应商没有做任何蠢事是很难的。

              当客户遇到问题时，为他们提供支持也很难。

              在有第三方参与的情况下调试问题很难。

              把认证外包出去并不意味着你就可以停止监控漏洞，或停止做其他所有你需要做的事情，以确保安全。

              将授权外包只会增加每个用户的经常性成本和复杂性，而你却会忽视这些成本和复杂性，直到问题比前期处理更严重为止。

              回复

              1. 我觉得没人说过你必须把认证外包给第三方平台。

                回复

            2. NextAuth 和公司也不会为你这么做。

              回复

      1. 酷毙了，让我们来赌一赌另一个框架吧，没人知道它明年会在哪里，也没人知道它是否还会存在。

        总有一天，人们会意识到，那些已经存在了很长时间的、包含全栈电池的框架还是有一定价值的。

        回复

          1. inertia.js 是他的选择（见他的评论）。其实还不错。

            我已经说过了：我的评论并不完全是认真的，我也讨厌这种框架跳跃……虽然 hono.js 很有前途。

            回复

      2. 又一个 JS 框架，看起来很棒。我只浏览了一下文档，但我已经喜欢上了它的简洁性。

        但我对大型 Context 对象的看法不一。它可能有助于减少代码的冗长，但也可能导致 OOP 的反模式 God Object[1]，尽管上下文更像是一个命名空间，而不是一个大对象。

          // Not
  app.get('/hello', (c) => { return c.json({ greet: `Hello ${c.req.params('id')}`)
  // But
  import { jsonResponse } from 'library'
  app.get('/hello', (req) => { return jsonResponse({ greet: `Hello ${req.params('id')}`)

        [1] https://www.wikiwand.com/en/God_object

        Fix: format

        回复

        1. Hono 非常棒，上下文对象实际上只是返回响应的辅助方法集合、在请求生命周期内存储值的方法以及 Req 和 Res 对象。我理解你的担忧，但我不会因此而放弃尝试。

          回复

        2. 我并不是完全认真的。我对下一个最佳框架的追寻已经结束了…我倾向于在我的宠物项目中使用 vanilla JS，而在更严肃的项目中，我会使用我觉得有趣的或项目使用的任何东西：-)

          回复

          1. 所以你不使用经过实战验证的框架（如 Laravel、rails、Django 等），而是自己发明？

            在我看来，这可不是个好主意。

            回复

            1. 这要看情况。如果是像我的个人待办事项列表 pure-todo [1]，我往往会在一周内写下它，而不使用任何框架，并且几乎不再碰它。

              如果是像 m4b-tool[2] 或 tone [3]这样需要维护一段时间的东西，我倾向于使用经过实战验证的库或框架（在本例中，Symfony 因为是一个较老的项目，而 Spectre.Console 和 atldotnet 用于 tone）。相比框架，我更倾向于使用库，这样可以减少后台魔法。

              不过，我感觉你在这篇评论中也发现了一些你不喜欢的东西–也许是对我的自由和开放源码软件项目的无耻宣传;-)

              1: https://github.com/sandreas/pure-todo

              2: https://github.com/sandreas/m4b-tool

              3: https://github.com/sandreas/tone

              回复

  2. 当我第一次发现 Next.js 时，就像发现了一座金矿。我再也不用使用 Express 服务器和 React，也不用管理所有疯狂的配置。Next.js 是如此简单，一切都能正常工作！

    文档非常棒，开发服务器速度超快，构建时间也很快，我可以轻松创建服务器端和静态网站，并将它们轻松托管在 Vercel 上，一切都很美好。

    后来，Vercel 与 React 合作，把事情带向了另一个方向。现在，React 几乎成了 Vercel 的孩子。突然间，重点从之前的客户端和服务器端瞬间转移到了服务器端。破坏性的变化、复杂性的增加以及两个路由器的奇怪共存，其中旧的路由器（顺便说一下，它运行得非常好）肯定会在不久的将来被淘汰，让我们别无选择，只能转移到这个 “新 “路由器上。

    Next.js App Router运行速度非常慢。你甚至不需要做任何特别的事情，只需比较一下 Next.js v12 和 v14 的开发服务器编译时间，性能就会下降。开发服务器有时会占用几千兆内存，为什么？

    我还能提到 “新的 “但更糟糕的基于文件的路由系统，它强制每个页面都命名为 page.tsx？谁认为这是个好主意？他们只是抄袭了 Sveltekit。这甚至迫使 VSCode 团队引入了一种编辑标签页名称的方法，因为每个页面都被命名为 page.tsx 无疑是更糟糕的 DX！

    所有美好的事物都会有结束的时候，Next.js 给我的感觉就是如此。我曾是 Next.js 的支持者，向所有希望使用 React 构建应用程序的人推荐过它，但现在呢？但现在呢？考虑到他们对自己的决定如此困惑（参考 v14 的缓存争议），我不再那么肯定了。

    一旦我找到更好的产品，我就会立即跳槽（我相信将来会有的）。目前，我只是因为多年来对 React.js 和 Next.js 的熟悉而坚持使用。它们为我提供了很好的服务，但就未来而言，Next.js 已经过时了。

    回复

    1. Next.js 在应用路由器方面一落千丈。页面路由器虽然并不完美，但却非常适合，是 React 方式的延伸（当时），可以很好地处理客户端。你可以在服务器端执行路由和某些功能，以及基本的 api 支持。至于其他功能，你可以使用完整的 express 后端，甚至其他后端语言/栈。但就像很多事情一样，简单的东西并不受欢迎，现在就出现了这种混乱的局面。是时候找到更好的替代方案了。

      回复

      1. 我认为 Inertia.js 就是答案。它只是一些 “粘合剂”，能让 React/Vue/Svelte 与任何经过实战验证的框架（如 Laravel、Django、Rails……或 Adonis，如果你想在后端使用节点的话）很好地配合（作为视图）。

        回复

    2. 在过去的 9 年中，我一直在使用 React，我讨厌 Vercel 对它的影响。我也讨厌他们对 Next 所做的一切，但至少那是他们自己的东西。

      回复

      1. 这是一家非常不光彩的公司，尽管看起来像，但与其说他们是一家技术公司，不如说他们是一家营销公司。

        我很庆幸自己及早发现了这一点，并及时停止使用 Next。对我来说，让我意识到这一点的是他们的 “隐藏”（尽可能地隐藏），并使其比 Next 的呼叫家庭度量系统更加困难。他们拒绝添加关闭该系统的设置，而是希望你设置一个环境变量或运行一条 npm 命令。

        想想看，他们这样做却拒绝添加设置。

        这样你就知道自己在和谁打交道了。

        回复

      2. 我也有同感，Vercel 正在摧毁 React。

        回复

    4. Express.js 出了什么问题？不，它现在有什么问题？因为在我看来，Next.js 只是 Express.js 的一个包装。

      此外，Next.js 正在变得像 Angular 一样：从 Angular.js 1 到 Angular 18 的进步是解决前端网络开发非常困难的问题所必需的。因此，我猜想 Next.js 的竞争者正在努力成为后端的 Angular。它们基本上正在变成它们必须成为的计算机科学理论构造。脚本小子和非计算机专业学生无需申请。

      回复

      1. 在 Express 上构建产品就像用种植小麦和养牛来制作三明治。当然，Next 是对 Express 的封装；JavaScript 是对汇编的封装。然而，有些人没有时间再从头开始做所有的事情，他们只需要一个合理的框架来构建。

        回复

        1. Express 就像是从超级市场购买面包、肉和调味品来制作三明治。NextJS 就像是从自动售货机上购买三明治。

          NextJS 等应用程序的最大问题在于，它们没有明确构建并公开 Express API。他们应该做的是通过在浏览器中运行路由处理程序的 Express 版本来实现客户端应用程序路由。他们还需要添加在浏览器和服务器上下文中运行的并行中间件。这是支持在服务器和浏览器上下文中运行的功能和组件的唯一合理方式。

          整个 NextJS 架构之所以存在缺陷，是因为他们选错了支点。

          我们希望用买来的组件制作三明治。有时，我们确实需要更换面包，而 NextJS 的抽象是错误的，这就导致了各种即将崩溃的更改–意大利面条来解决这些缺陷。

          如果能直接使用请求、请求中间件和请求路由处理程序来维护应用程序，并在客户端使用与鼠标事件相对应的模拟请求，效果会好得多。

          请求-响应循环是网络应用程序的基本特性，即使在浏览器中也是如此。

          回复

        2. 由于规模经济，用自己的小麦和牛来大规模制造理论上的三明治，最终应该比现在的替代方案更便宜（与现在的替代方案相比）。而在这种大规模生产中，这是唯一有效和实用的选择。因此，我们可以推断出这样的结论：Express.js 和 Next.js 之类的软件开发存在多种不同类型。即真正的开发人员和像工厂生产线上的奶牛一样的低级开发人员。

          回复

      2. > Express.js 出了什么问题？

        设置它很麻烦，托管它也很麻烦。别误会，Express.js 是个很棒的工具，但在使用 Next.js 之后，我就再也不需要它了。

        现在有了 Hono (https://hono.dev)，它就像 Express.js，但更好用。

        回复

        1. > 设置它很麻烦，托管它也很麻烦.

          怎么可能有活跃在这个行业的人认为建立快递是件麻烦事？

          回复

          1. 他们被提拔为高级+，主持大局。”灰头土脸的人回家吧，未来就是现在”？

            回复

        2. 如何正确设置快递和托管网络服务器？

          >hono

          在我看来完全一样，他们的启动显示没有登录 mw（只有已标记的 auth），而且只是一个上下文参数，而不是（req, res, next, res.{text,json}）。这有什么新意？感觉就像又一个可爱的解决方案在找问题。

          回复

        3. 我还以为 Next.js 是一个后端框架。我一定是想错了。我错把一件事和另一件事混为一谈了。没关系，笑一笑

          回复

        1. Dropbox 的事只是个我不明白的笑话。如果你愿意，我不 “参与 “这个笑话。我不明白 Dropbox 这个笑话和这里有什么关系。

          回复

          1. https://news.ycombinator.com/item?id=9224

            如果你愿意的话，这也是 HN 历史的一部分，它轻描淡写地嘲笑了 “这只是一个封装 “的想法，却让它转变成了一家价值数十亿美元的公司，因为只有天真地认为执行和整合不同的想法才是一件微不足道的小事。显然，NextJS 的员工们（？）正在做的事情不仅仅是 Express，如果你有兴趣了解这些事情，可以查看其版本历史。

            当然，你可能认为它们并不重要。但这是截然不同的看法。

            回复

      1. 这看起来不错，我还是第一次看到。只是好奇，什么地方感觉粗糙？

        回复

        1. 就是所有东西挂在一起的方式。它可以工作，但有些东西在代码里有，但文档里没有，网站上也有提到，但他们提到的启动工具没有这方面的功能，所以你需要自己连接。

          回复

      1. 我不喜欢 Svelte 晦涩难懂的语法和不断的变化。他们一开始做得很简单，这也是我决定使用 SvelteKit 构建 upscayl.org 简单网站的原因，但现在与 Next.js 相比，SvelteKit 简直太麻烦了。

        他们改变了整个状态管理系统。现在就像在使用一个全新的框架，而且看起来非常像 React，这很奇怪，因为 Svelte 本应与 React 不同，并提供代码的简洁性。

        我认为现在最好的竞争者是 Solid.js，但它需要一些资金帮助和 Next.js 的花哨来吸引更多的开发者。

        回复

        1. 我和你一样对基本概念不断发生大量变化感到沮丧，但总体而言，我仍然觉得 SvelteKit 做对了很多 Next 做不到的事情。

          回复

          1. 我认为 SolidStart 框架很好地将 Svelte 和 React 的优点结合在一起。我对它的发展非常感兴趣，可以说它比 Next 或 Sveltekit 更有前途。

            回复

            1. 不幸的是，Solid 的发展速度在一段时间内有点疲软，缺少了自己的炒作。在这一点上，Svelte 要比 Solid 大很多很多倍。

              回复

            2. 是的，我是 Svelte 4 的超级粉丝。我根本没用过反应，但我看了一眼 Svelte 5 就觉得很难过。

              我现在又回到了 Vue。

              回复

      2. Svelte 有很多神奇之处，如果你喜欢这种东西，那就再好不过了，但每次我试过之后都会感到沮丧和失望，于是就把项目转到了别的地方。

        回复

    7. 加入我们的 Vue 团队吧！根据我的经验，使用 Vue 和 Nuxt（如果你需要 SSR）绝对是一种工作乐趣。

      回复

      1. 我很想喜欢 Vue，但漏洞百出的语言工具和漏洞百出的元框架结合在一起，给我留下了不好的印象。看看代码质量也就不奇怪了。

        回复

      2. 我一直很钦佩 Nuxt，因为它总是能推出令人惊叹的功能，Next 一直在模仿它，但我从未尝试过。

        也许是时候了。

        回复

      3. 他们也不是没有打垮过所有人……

        回复

          1. Vue2/vue3 ？我知道有几家公司还没有更新，有些可能永远也不会更新。

            我工作过的一家公司就有一个大型的 nuxt 应用程序，但他们很快就无法升级了。

            回复

  3. 由企业支持的软件工具在面向企业时会面临非常大的压力，它们会变得模糊、复杂，而且通常会为了机构目标而进行优化，远离开发经验和效率。随着被开发者采用的工具进入高端市场，对使用这些工具进行开发的人来说，它们会变得越来越糟糕。

    回复

    1. 这很好地提醒了我们应该如何感谢自由软件的众多贡献者。

      回复

    2. Vercel 开始榨取平台利润，因此我们也看到了上面的 “ensittification”。

      回复

    3. 我想知道是否有可能保持在正确的（开发）轨道上？可以说，当它变得糟糕时，迟早会被抛弃。

      回复

  4. 感觉整个 JavaScript 世界似乎都受到了电子商务的过度影响，推动了各种优化，甚至包括 RSC 和 SSR。作为一名前 SaaS 构建者，我对作者的观点深有同感：

    “我更关心的是发布功能的速度，而所有这些复杂性都会成为我的开发团队的负担”。

    这正是我开始构建 ZenStack(https://zenstack.dev) 工具包的原因。我们的目标是使用你喜欢的任何框架，让构建 SaaS 应用程序回归简单。

    回复

    1. 关于页面的一些反馈：我发现简介[1]中的公司名称有点令人反感。即 “超级充电，释放潜能”，让人一看就有一种 BS 的感觉。

      我不知道其他受众是怎么看的，但我猜，比如 HN 受众平均来说是不喜欢的。那就用空格写出它的实际内容和作用？

      这绝对不是最严重的违规行为，这可能就是我想提出反馈意见的原因。

      [1] “A TypeScript toolkit that supercharges Prisma ORM with a fine-grained Authorization layer, auto-generated type-safe APIs/hooks to unlock its full potential for full-stack development”。

      回复

      1. 感谢您友好而周到的反馈！我们已经进行了更改。

        回复

    2. 这只是 React 世界的情况，当然，这也是 JavaScript 世界的大部分情况。

      在 Angular 的世界里，并没有发生什么。好吧，我们现在有信号了，但也仅此而已。

      如果您想要简单，请使用 htmx 和您选择的后台框架。

      回复

      1. 我对整个 React 和复杂性的看法是：它并不好，但同时也不像某些人说的那么糟糕。

        事情_可以_以简单的方式完成。React 的问题在于它只是一个库，它留下了一些空白，像 Vercel 这样的公司试图填补这些空白（并且滥用了这些空白，但这是另一个话题）。于是，你就会遇到一群新手开发者，他们甚至还没好好学过 React，就把一堆他们也不完全了解如何使用的随机库扔了进去，结果就成了一锅烂汤。这并不是因为配料不好，而仅仅是因为厨师不知道如何使用它们。

        我见过有人滥用 React。我见过有人滥用 Redux（和扩展）。即使两者都有充足的资源。

        人们想在没有提前规划的情况下发挥创意，然后事情发生了，业务想要继续，但开发人员很少有时间去整合和应用他们从以前的错误中学到的东西等。

        因此，虽然有些问题是技术性的，但我认为最大的问题不在于技术本身，而在于技术如何与缺乏经验的开发人员相结合。

        尽管如此，我也非常喜欢设计易于使用、难以滥用的 API。不过，React 的应用程序接口在这两个原则上都存在不足（我认为他们希望通过 React 编译器来解决其中的一些问题）

        回复

      2. 几年前，我曾开发过一个大型的单片 angular（当时是 v8）应用程序，我想我的老同事们听我回忆起这件事一定会大笑不止！

        作为前端框架，Angular 的布局其实非常漂亮。我发现现代的 react 生态系统比以前的 Angular 应用程序更加愚钝。

        回复

      3. >×在 Angular 这块土地上，并没有发生太多事情。好吧，我们现在有信号了，但仅此而已。

        我把它的安静（相对安静，至少是安静）作为其可取之处之一，也是其稳定性的一个例子。

        回复

        1. 我开玩笑说，这是有孩子的人的首选框架。你可以离开工作岗位一年之久，但当你回来时，一切都还是老样子。

          此外，它还能将所有追逐刺激的人拒之门外，这对于在预算范围内按时完成任务非常有帮助。

          当然，如果我们能有一些舒适的环境，比如快速的编译时间和良好的默认性能，那就更好了，但不能以引入 React 人员生活和呼吸的混乱为代价。

          回复

      4. 我不明白为什么 HN 喜欢憎恨 angular。它是一个令人惊叹的、包含电池的框架，你无需从 100 种不同的选择中进行分析，它易于上手和学习，始终如一，性能相当高，而且不会让你的构建年复一年地中断（或像其他一些框架那样月复一月地中断）。(或像其他一些深受 HN 喜爱的框架那样月月如此）

        React 让我害怕。没有什么是一致的。所有东西都有一点坏，维护起来非常痛苦。这是我在 3 个不同的 React 项目中做维护工作的亲身经历。

        当前项目的框架使用 Vue 和 Vuetify，这是一次非常愉快的经历。在这三个框架中，Vue 是最容易上手的。(尽管 Angular 仍是最稳定一致的框架）

        回复

    3. 啊！又一个可以解决之前所有框架问题的 js 框架……太好了…

      回复

      1. 别紧张没人会抢走你宝贵的 jQuery。

        回复

        1. 不，我写我的业余爱好网站时不使用 JavaScript。

          回复

        2. jQuery不是一个框架。作为一个库，它还是很珍贵的。

          回复

          1. 我不认为这种区别是影射的关键所在

            回复

      2. 我的意思是，潜力总是存在的，但我宁愿完全避免使用太多的 JS，只使用极少量的 JS，而这通常不是 JS 框架想要让你做的。

        回复

        1. 我就是这么做的。我在编写自己的业余爱好网站时，不使用任何 JavaScript。

          回复

      3. 你竟敢对技术喜鹊嗤之以鼻。

        它们确实喜欢收集闪亮的东西！

        回复

  5. 我做过大量的网络性能分析工作，只要我在网络工具中看到 nextjs bundle 下降，我就知道会有问题。

    与我见过的其他堆栈相比，它显得异常缓慢。至于是文档不完善还是实现不佳，我还不能完全确定，但它似乎有一个很大的问题–在我的分析中，我没有发现任何其他堆栈存在与 nextjs 一样多的问题。

    我发现的主要问题是其服务器端渲染的 TTFB 特别差。这就促使人们积极地进行各种类型的缓存（通常并不完全了解缓存管理的后果），从而改善了情况，但直到用户 eg 登录后，很多时候又会回到原点。

    第二个问题是水合时间过慢，无论采用何种 SSR/缓存方式。这给交互性带来了很大的瀑布流问题，因为在大部分（任何）交互性可能实现之前，nextjs bundle 仍然需要水合。

    虽然所有 SPA 类框架都会遇到这种问题，但 nextjs 似乎更上一层楼，而且当我报告这些问题时，解决起来似乎并不容易。

    回复

  6. 无用的轶事：我没有使用 Next.js[1] 的直接经验（但有使用 React、Angular、Vue、Solid 的经验），但我确实帮助过一位同事处理过他们 Next.js 应用程序中的一些问题，而当我看到基于文件的路由这种疯狂的方式时，我立刻就放弃了整个项目。

    [1]：主要是因为我对现代形式的 SSR 从未产生过兴趣，因为我认为那是对 SEO、TTFB 和页面加载性能的一种真正不彻底的解决方案，这一点颇具争议。无论整个行业在这方面花费了多少亿工时，你都无法通过在上面堆砌更多的问题来真正解决问题。

    回复

    1. 基于文件的路由是应用程序达到特定规模的最佳选择之一。与遍布整个代码库的路由相比，它能让代码导航变得更容易。

      回复

      1. 你不需要根据应用程序的路由方式来构建代码库

        更重要的是，如果应用程序的路由发生变化，您不需要重新构建代码库

        基于文件的路由是个糟糕的想法

        回复

      2. 如果你有一个单一的路由源，那就会变得同样简单，不过这确实取决于人们是否为路由指向制作了合理的路由处理程序，如果人们不善于这样做，显然 /pages 的隐式顺序更胜一筹。

        回复

    2. 我不认为基于文件的路由是邪恶的，它在 Nuxt 上运行得很好。

      回复

    3. 将 SSR 与 CSR 结合起来的混合网络应用的想法实际上非常有趣。它能带来更丰富的体验。

      回复

  7. 不久前我用过 Next.JS，感觉非常好。后来我改用 Remix，也很不错。后来我又用回了 Next.JS，我不知道哪里出了问题。从路由模型到部署模型，一切都感觉很糟糕，我无法说服自己继续使用它。

    回复

    1. 你目前会推荐 Remix 还是 Next.JS？我刚刚开始了一个 Next.JS 项目（作为 Gatsby 的长期用户，我正在尝试使用它），但我对在这里读到的内容感到担忧。

      回复

      1. 在我开发的几个 Web 应用程序中，我经历了从 Remix 1 到 Remix 2 的艰难过渡，但总的来说，我还是觉得 Remix 模型更好用。尽管如此，我可能不是推荐 Remix 2 的最佳人选，因为我正在寻找一份正常的工作，使用.NET MVC 或 PHP Laravel，并在上面添加一些动态前端。

        回复

      2. 从 Gatsby 迁移到 Next 的页面路由器绝对是一次升级。页面路由器非常棒，而且易于理解。

        回复

      3. 它是由 React Router 制作者开发的，他们对代码库进行了 6 次不同程度的重构，每次都会带来破坏性改动，给那些使用过它并希望升级的人带来了很多痛苦。这也是我最近不想使用 Remix 的主要原因。

        回复

      4. 我愿意；它更易于使用和推理。话虽如此，但感觉我们又回到了 00 年代初，用表单帖子提交更改，而不是 fetch/xhr

        回复

  8. 真正的问题：对于 90% 的中小型 SaaS 应用程序而言，客户端 SPA 和服务器端后台有何不妥？

    我明白为什么 Vercel 希望每个人都使用 SSR 及其不透明的服务器端缓存，但为什么普通的非 FAANG 规模 Web 应用程序第一天就需要它呢？

    当 Next 成为 Vercel 的销售工具时，我改用了 React + Vite + 后台，一切都变得简单多了。

    回复

    1. 前端开发人员在很大程度上是被人们发布的关于 SPA 和加载旋转器的备忘录所欺凌，不得不模仿传统的 MPA。很大一部分页面都可以简单地预先渲染（例如静态登陆页面和文档网站），或者它们位于登录墙后面，在这种情况下，搜索引擎优化就不再重要了。过去，部署 SPA 意味着将一些脚本和 html 文档上传到 S3 存储桶，再加上 CDN 缓存，对许多企业来说速度已经足够快了。Instagram 大部分仍是 100% 客户端 SPA。

      回复

      1. 我可能也会死在构建的山上：

        1.使用托管在 cdn 上的 html css 和大量 js 的 SPA，与纯 REST api 对话。

        2.Php 风格的服务器渲染页面，内嵌 jquery-ish JS。(用于网站）

        两者的混合体是一个科学怪人，我不会去碰它。

        回复

    2. > 对于 90% 的中小型 SaaS 应用程序来说，客户端 SPA 和服务器端后台有什么不好？

      我不是前端开发人员，我喜欢 SSR 的原因是，你不需要编写前端视觉效果代码来显示 “有东西正在加载”，你只需要返回水合页面，而不需要太多的前端逻辑。

      回复

      1. 仅仅为了避免添加 <suspense> 标签，就带来了如此多的复杂性

        回复

    3. 如果搜索引擎优化并不重要，那么这种方法就没有什么问题。

      回复

      1. 停止制造从广告中获取收入的产品，搜索引擎优化的烦恼就会烟消云散

        它其实很棒

        回复

        1. 这与广告无关，而是与分销有关。如果人们通过谷歌找到你的产品，那么搜索引擎优化就很重要（至少对于他们登陆的页面）。

          回复

          1. 你的营销网站应该进行搜索引擎优化

            它也不应成为产品代码库的一部分。

            您无需担心产品本身的搜索引擎优化问题

            回复

            1. 人们想把所有东西都结合在一起，比如在定价页面上的一个按钮上添加一些衬垫，就会重新部署整个后台，这太疯狂了……

              通常情况下，我的后端服务器是用一种好的语言编写的，应用程序本身是用 SPA 编写的，然后是一些用普通 html 和 js 编写的营销页面。这对搜索引擎优化很有帮助。

              回复

            2. 我也在营销网站上使用 Next.js。它是在 React 中设置 SSR（或发送纯 HTML 和 CSS）的最简单方法，即使用 JSX/TSX 作为类型化模板语言，并能在需要时为某些内容引入 React 包。

              回复

  9. 大约 2.5 年前，我用 next 启动了一个项目。该版本相当不错，易于推理。

    大约一年前，我启动了一个新的 next 项目，但却遇到了一些非常不直观的错误，比如试图在服务器页面中使用客户端库？诸如此类的错误。我不知道自己是疯了，还是这真的是一个糟糕的方向。

    回复

    1. 我有几个相当大的 Next.js 项目，是几年前开始的。其中一个项目在经历了大量错误、弃用和研究文档之后，我成功升级到了 Next 的最新主版本。现在要记住的小细节和规则太多了，就像 React 一样。从用户的角度来看，这些看似不利于用户的设计决策并没有带来多少明显的好处。

      第二个项目出现了一个难以理解的错误，导致无法完成生产构建步骤，在搜索了 GitHub 问题，甚至进入 Next.js 代码库后，我都无法解决这个问题。在这一点上，我放弃了升级，转而寻找另一个框架来重建应用程序。它有数百个页面，其中许多是由动态 URL 路由生成的，所以我并不期待它。光是让应用程序像以前一样运行，就需要付出巨大的努力。

      这次升级让我对 Next.js 失去了兴趣，我不会用它来启动一个新项目。即使是 React，我也对它最近的发展方向产生了怀疑，并开始关注其他视图库，希望能实现它曾经拥有的简洁性。

      回复

    2. 我没有接触过 Next，但在我使用的一些东西的讨论和问题中，人们似乎都认为自己是在客户端，而其实是在服务器上，反之亦然。

      有人在主题中提到了一些常见的 Auth 脚枪，我一点也不感到惊讶。

      也许警告就是为了减少这种情况。

      回复

  10. 这篇文章中围绕 App Router 的负面情绪让我很害怕采用它。

    在过去的两个月里，我一直在使用它，而且非常喜欢。最大的原因是它可以直接从服务器端或客户端代码中调用函数！现在，你基本上只需要为面向外部的服务编写 API 端点。节省了大量时间和模板…

    是的，它比 Pages Router 更复杂。虽然我坚定地主张尽可能简化，但我认为对于新项目来说，这样做是值得的。只是需要一点时间来适应。这种消极的感觉有点像钩子的感觉……

    回复

  11. 人们也把 Next.js 用作 API 服务器吗？在我加入的所有项目中，我们都只是将 Next.js 用作构建在 React 之上的静态前端框架和开发工具。我们从未接触过 SSR 功能，只是将其用作静态网站生成器，也没有费心在 Next.js 中实现任何 API。我无法想象有人能在混乱的文件夹结构中混合前端和后端代码的情况下实现一个强大的代码库。

    回复

  12. 作为一个通过 HTTP 发送 HTML 开始从事网络开发的人，我对现代网络开发人员为了能够发送 json 而扭曲自己的方式感到惊叹。

    回复

  13. 我不是一名前端开发人员，但在过去 6 个月里，我一直在使用 NextJS 构建一个网站，而且我一直在使用 App Router，因为我想使用 SSR，而且 NextJS 建议我使用 SSR。

    目前我感觉很好，尽管我在努力让事情尽可能简单，所以你可能会说我并没有把它推向极限。

    我遇到的主要 “问题 “是将服务器组件和客户端组件混合在一起，因为我不可避免地倾向于将事情搞得过于复杂：如果我需要任何形式的客户端交互，那么我就必须使用 “use client”（使用客户端）来标记，但这样一来，你放在该组件中的所有东西也都变成了客户端组件。如果要在客户端组件中保留服务器组件，就必须通过使用 {children} prop 来传递，这有时并不理想。

    回复

  14. next js 是一个无意中故意将事情复杂化的项目。在某一点上，一切都进行得很顺利，但在某一点上，你会发现自己陷入了服务器 <-> props 的地狱。

    回复

    1. 如何在无意中故意把事情搞复杂？

      Next.Js无意中把事情搞复杂了，因为他们认为基于文件夹的路线映射很好，而且显然能满足客户群的需求。

      然后，他们就陷入了无法挽回的境地。

      哎呀。

      回复

  15. 作为一名 [主要是] 后端开发人员，我的观察结果是，JS 界普遍热衷于构建复杂性，然后用更多的复杂性来解决之前的复杂性。反转器、转换器、树形振动器，天哪。现在是 2024 年，构建网络应用不应该是火箭科学，也不应该需要如此猥琐的工具链。

    与此无关，但我一直在努力完成我的一个项目，经过长时间的休息后，我会发现我的前端代码已经过时了。已经有了更好的框架或新版本，你的旧代码已经过时了。在 Vue 3 引入合成 API 后，我就放弃了–我所做的只是学习 “新方法”，却没有实际构建任何东西。

    后来，我改用 HTMX，抛弃了所有这些废话。

    回复

    1. 使用 HTMX 和 GoLang，比使用其他任何网络相关应用程序都要轻松。

      我们仍在使用 NextJs 和 NX（坦率地说，这也是不必要的，因为它所做的一切都可以通过 pnpm 工作区和 vite 非常简单地完成）、复杂的故事书设置以及 90 亿个组件库、实用程序库等进行单核开发。尽管现在已经是 2024 年，任何语言中的函数都应该能够独立于类之外，但我们仍在使用 C# 语言……自然而然地，”简洁的架构 “和 “稳固的 “使得整个代码库变成了一个由不必要的抽象组成的大杂烩，一个只做一件事且永远不会被重新实现的简单助手被放在多个不同的 csproj 中的 90 亿个文件中，因为有一天它 “可能 “需要被抽象出来（不会的）。

      与使用 HTMX 和 Go 开发整个内部服务相比，我需要更长的时间才能弄清这些项目的进展情况……尽管这对每个人来说都是一个巨大的成功，也受到了企业本身的欢呼，但对我们的未来计划却没有任何影响。我们可以坐在一个会议上，看着每个人都用 HTMX 和 Go 取得了了不起的成就，却仍然决定继续使用 NextJS 和 C#。这很愚蠢，但我从未在一家公司真正工作过，因为它并不愚蠢，至少我们不会被自己困住，无法使用 “非战略性 “工具构建东西。

      回复

      1. 如果你认为 Go 是比 C# 更好的选择，那可能是你花了太多时间在 youtube 和 twitch 上观看有影响力的技术人员的演讲，而很少花时间编程和熟悉他们所散布的虚假信息。

        Go 在性能、包管理、简洁性和表现力等所有可能的维度上都比 C# 差–众所周知，Go 带来了更多的模板，Go 在编写 Web 应用程序方面拥有较差的生态系统、较差的 ORM 和较差的工具来解决生产中的高级问题–这样的例子不胜枚举。

        有些公司对 C# 不屑一顾，但你一定不愿意看到他们用 Go 来做什么。

        回复

        1. 我不知道你怎么会觉得我攻击了 C#，只是觉得它有不必要的臃肿，要求函数存在于类对象中。至于将所有东西分割成 90 亿个文件和项目，C# 并没有强迫你这么做。我并不太介意 dotnet，我已经用它工作了十年，它从未像现在这样好用。不过，如果可以选择，我绝不会在新项目中使用它而不是 Go。我真的很好奇您为什么会这么说：

          > Go 在编写网络应用程序方面的生态系统较差

          就我个人而言，std http 处理器是我迄今为止在网络开发方面获得的最好体验。不过，我猜想你可能在使用标准版之前就已经使用过 Go 了，如果是这样的话，你的经验可能会因为生态系统太像 “节点 “而受到一些 “玷污”。

          > 更糟糕的 ORM 和更糟糕的生产中高级问题故障排除工具

          虽然这是个人喜好，但我并不特别喜欢微软 C# 软件包丰富的调试功能。正是因为在生产中很难使用它们。这取决于您拥有什么样的生产环境，但我们的 dotnet 应用程序也依赖于开放式遥测技术。至于 ORM…我们的运行规模无法使用它们。实体框架很不错…只是业界已经不再需要 ORMs 了。即使你的团队设法避免了懒加载的陷阱，你的 ORM 最终也会比不使用 ORM 更复杂。部分原因是 ORM 并不是为扩展契约模式（Expand Contract Pattern）等设计的（你可以实现扩展契约模式，但这样你要做的工作就比简单编写原始 SQL 多了），但主要原因是 LLM 使得提高工作效率和保持对数据的控制变得非常容易。

          > Go 带来了众所周知的更多模板

          我可以写一个结构和一个函数，然后在我的类型上调用它，所需的代码行数比完成整个命名空间所需的代码行数还要少…所以我真的不明白你的意思。如果是 C# 在幕后施展的魔法，我认为是否需要控制权取决于您的个人意见。你可能已经从我对 ORM 的看法中猜到了，我更喜欢透明度和控制。

          回复

    2. 我最喜欢的理论是，由于零利率政策，太多的初创企业能够筹集到太多的资金，因此他们雇佣了太多的工程师，而这些工程师多年来都没有真正有价值的事情可做。于是，他们在十多年的时间里不断重塑轮子，每一次迭代都比前一次更加复杂。

      回复

      1. 这就是我所相信的，也是我在撰写《千微服务之死》（Death By a Thousand Microservices）一书时提出的重要观点之一：

        https://renegadeotter.com/2023/09/10/death-by-a-thousand-mic…

        我认为这两者是相关的。

        在一个真正精益的商业环境中，人们不会有那么多时间去摆弄这些框架。实际上，开发人员似乎是先想出了一些拗口的库和框架名称，然后才真正去编写它们。

        回复

  16. 作为一个重返网络开发并首次尝试 Next 的人，当我得知我使用的是这个半生不熟的App Router，而不是更直接的页面路由器时，我感到非常沮丧。

    他们的常见问题问我是否有基于App Router的开源应用程序：https://nextjs.org/docs/app#are-there-any-comprehensive-open…

    回复

    1. 更不用说，由于 Vercel 的所有权，Next/Image 永远不会支持 Google App Engine，也不会在环境变量或编译时指定图片缓存目录。

      回复

  17. 我认为由 Vercel 来推动 RSC 和新 Next 的所有复杂性是非常有意义的。

    – 他们卖的是计算/带宽。如果人们正在构建从 CDN 加载并在客户端执行的 SPA，就不可能赚大钱。

    – SSR 可以为他们提供一些服务器计算能力，但只要加载了初始页面，我们就又回到了第一点。

    – 这时，RSC 出现了。他们大力推动。让它看起来像有史以来最好的东西。初始加载时间是最重要的指标。你必须确保在任何基准测试中达到这个分数…

    – 他们还收购了 React。现在基本上是 Vercel 的了，所以他们可以主导开发方向。

    – 所有这一切对开发者来说几乎没有任何好处（与下一个预应用迭代之类的东西相比），但很可能在收入方面对他们有很大帮助。

    我的意思是，这可能读起来像一篇 “Vercel 邪恶 “的帖子，但这就是公司的工作，而且他们似乎做得很好。

    我最近在一个项目中使用了 next，但不会再碰它了，因为在我们自己的开发过程中，炒作并没有带来任何收益。

    回复

  18. 使用 “得天独厚的 “Next.js 方式在屏幕上显示一个模态是多么令人费解，我永远也忘不了。你需要并行路由、插槽、拦截路由，文件名看起来就像出错的 shell 脚本的爆炸半径，名称中包含 (..) s、[slugs] 和 @slots，还有一些特殊用途的文件名，如 page.ts、index.ts、default.ts，以及一些作为道具自动传入的东西。

    这就好像他们试图从 Rails 这样的软件中汲取灵感，但却从未使用过 Rails，然后再将这些灵感改头换面。

    我知道我听起来过于挑剔了，也许是我太苛刻了，但我就是觉得 Next 开发人员对神秘的复杂性有一种奇异的欣赏或崇拜。而任何简单直接的东西都会被回避和皱眉。就好像简洁在某种程度上有失他们的身份，简洁只适合像我这样的蠢货。

    我没用过 Remix，但他们的文档显示 Remix 更简单。

    回复

  19. 我正在构建一个 nextjs 的替代方案，它只有 3 个文件，没有外部依赖。

    https://github.com/spirobel/mininext

    (我对 mininext 的目标是提供类似于 index.php 的生产力，但所有的 npm 和 typescript 都触手可及）

    回复

  20. 我最近避免使用 node.js 的所有 SSR，并不是说它们不好，而是：

        1. it's a mature field with many solutions already, no need reinvent the wheel for me.
    2. the frontend is complex enough
    回复

  21. 由于App Router的复杂性，我仍在使用页面路由器。在这一点上，我认为我会转向其他框架，而不是应用路由器。他们完全搞砸了从页面到App Router的过渡，即使是几年后的今天，仍然有一些简单的事情是App Router做不到的。此外，默认使用服务器组件也非常令人困惑。很遗憾，因为在一开始，Next.js 是一股新鲜空气。

    回复

  22. 对于我（和我的公司）来说，Inertia.js 是未来的方向。

    它能让 react 或 vue 与真正的后端框架（如 Laravel、Rails、Django 或 Adonis）搭配使用（美轮美奂）。

    我已经受够了每周都会出现的 “全栈框架”，它们除了路由之外什么都做不了，而且前途未卜。

    回复

  23. 我很想知道有哪些替代方案能提供良好的基于文件的路由支持。有人见过好的替代方案吗？

    回复

    2. Nuxt 开箱即用。它可以变得像 Next 一样复杂，但（大部分）枪支并没有像 React 世界中的所有东西那样已经上膛、上膛和瞄准（跳过组件的自动导入，那个最终会咬到你）。多年来，我一直用它来构建完全静态的 SPA，在这种模式下工作时，它从未对服务器端的逻辑做过任何提示。Suspense 就是这样工作的，当你有一个异步组件时，它就会自动运行，而不需要你做任何额外的工作。

      是的，它内置了一个相当不错的文件路由器，useRoute() 在任何地方都能正常工作。如果你只想要文件路由，那就跳过 Nuxt，使用 vite-plugin-pages（它也适用于 React）。

      回复

    3. SvelteKit 很不错，但也可以考虑 Deno Fresh。

      回复

      1. 我真的不喜欢 Remix 把他们的理念塞进你的喉咙。旧版至少更自由。

        回复

        1. 如果你同意 Remix 的理念（经过多年的前端开发，我想说我同意），那它就是天堂。在我看来，现在的新 Next 与旧 Next 一样有主见，而且更糟糕。

          回复

      1. 字面意思。我在路由工具方面的经验是，与其整合现有的通用解决方案，还不如从头开始完全根据自己的使用情况来实现它。

        回复

        1. 是的，就是这个意思，老兄！

          当市场不能满足你的需求时，你就去满足市场。

          回复

  24. 现在最难的是忘记我们在客户端使用的所有模式。

    在成功提交表单时，根据错误状态更改界面。

    现在，由于服务器的操作，你将会直接重定向到成功页面。

    这其实更简单。它让人想起 Django/Rails/Wordpress 这样的完整 SSR

    回复

  25. 最后，这有助于我决定在项目中使用 Nextjs 还是 Reactjs。

    回复

  26. 我希望看到一个像 Next 这样的 Webcomponents 全栈框架。所有全栈框架都缺少一样东西：内容管理系统。Astro 和 next 非常不错，但我无法为客户提供 markdown 或 jsx。

    回复

    1. Primate 与此接近–有一个支持道具的 webc 处理程序：https://primatejs.com/modules/web-components

      webc 处理程序确实缺少一些东西，比如水合作用，如果用户对此感兴趣，可以添加水合作用。

      回复

  27. 我认为 Vercel 的产品不错，而且显然有才华横溢的工程师在那里工作，但他们对 React 生态系统的接管令人震惊。为了让人们使用 Vercel 平台，他们采取了 “拥抱-扩展-熄灭 “的策略。

    回复

  28. 就用 remix 吧。这样既简单又省事。

    回复

  29. 只要它能继续成为节点上最接近 Spring 和 ASP.NET 的产品，我就能接受它的发展方向。

    回复

    1. 我认为 https://adonisjs.com/ 与之相当？我已经有几年没用过 next.js了，但除了渲染之外，它似乎无法解释后端的任何问题。这只涵盖了 Spring 或 ASP.NET 等框架所能提供的一小部分。

      回复

      1. 你在后端使用 API 路由，即典型的控制器，也就是现在市场营销中所说的 Backend For Frontend。

        回复

    2. 是什么让它与 Spring 和 ASP.NET 最为接近？

      回复

      1. 可在服务器端呈现的 React 组件（JSP 标签库、Razor 视图组件）、中间件（servlet、中间件）、API 路由（控制器）的组合。

        回复

  30. 如果你厌倦了那些废话，不妨看看primatejs。

    回复

    1. 嗯……听起来不错，但有些事情让我很担心：

      1.”在开发过程中使用一种运行时的舒适性，而在生产过程中使用另一种运行时的速度优势。”这怎么可能不产生各种向后/向前兼容性问题。

      2.您在首页给出的 react 示例似乎不太像 react。

      – 您在首页上给出的反应示例看起来并不像反应，而是说 “利用 Wasm 的强大功能，用您选择的语言编写后端代码。混合不同后端语言的路由，允许不同团队编写应用程序。”听起来你可能会觉得谁会需要这样的东西，但我曾在几个团队工作过，现在我所在的团队或许就能从中受益。

      而现在的情况是，有一个 JS api 会将请求转发到实际的后台–也许会进行一些最低限度的验证等，因此工作会加倍–不是在所有地方，而是在某些 api 端点，我们不想在前端等地方泄露机密。

      回复

      1. 关于 1，兼容性由一个单独的库处理，Primate 的唯一依赖库 rcompat: https://github.com/rcompat/rcompat；它是 Node、Deno 和 Bun 的统一兼容性层。

        至于第 2 点，你认为什么是类似 React 的示例？前端的示例旨在说明不同前端之间的共性。

        回复

      1. 它允许你使用任何你想要的界面框架

        回复

        1. 那它能做什么？

          它和 Vike.dev 类似吗？

          回复

          1. 它允许您使用 vue、react、svelte、angular、htmx、solid 等….，后台可以使用 Go、python、bun/node/deno 和/或 typescript。我们还即将发布一个新版本，允许使用原生桌面应用程序（即：Tauri）。

            回复

  31. 我认为，业界正在缓慢地放弃 React 生态系统（这是对 React 影响力的巨大肯定），转而选择像 Vue/Nuxt 这样没有任何 React 生态系统问题的更理智的选择。

    说到底，React 的弱点永远是它的渲染函数模型，虽然很好推理，但几乎不可能预编译。这将使 React 的速度永远慢于基于模板和指令的替代方案，因此人们需要疯狂地开发才能获得性能良好的 React 应用程序，而这一切都不是开箱即用的。

    回复

    1. 在 V3 过渡期间，我从 Vue/Nuxt 2 转向了 React。原因是可怕的缓慢开发性能、缺乏模板类型检查以及生态系统向 V3 过渡的整体缓慢。

      回复

      1. Vue 的创建者同时也是 Vite 的作者，Vite 在设计之初就考虑到了 Vue 的开发，而且它的速度并不慢。

        回复

发表回复

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