JavaScript 框架选择困难症仍在增加

47 条评论 | |

最近几个月，我重新开始每天写代码。这给我带来了很多乐趣。虽然我喜欢 Swift、Python 和 Ruby，但最近我们一直在用 TypeScript 构建，因为它非常适合我们的最新项目。

大约有十年没有定期编写 JavaScript 了，现在能一下子赶上十年的进度，感觉非常有趣。举个例子：

  1. React 已经从一个被认为能提高性能的小实验，演变成了一个被认为会阻碍性能的庞大生态系统。
  2. ES Modules、fetch、视图转换和 async/await 等平台特性使网络成为了一个更适合直接构建的平台。
  3. 无服务器已从一个天马行空的新想法变得广为人知
  4. 光标尤其擅长在 TypeScript 中工作，这在很大程度上消除了繁琐的模板工作
  5. 现代构建和打包工具（如 vite、ppm 和 esbuild）让 JS 工具变得更漂亮、更快速
  6. 所有这些都使通用 JS（在客户端和服务器之间共享代码）从几乎不可能到得到良好支持

这些变化都以各自的方式促进了生态系统的发展。但有一点始终未变：选择合适的 JavaScript 框架很难。

十年前，我曾试图理解为什么没有出现类似 Rails 的 JavaScript 框架–功能丰富、维护良好，并且是初创公司构建新产品的理想默认选择。问题在于，与 Ruby、PHP 或 Python 不同，大多数 JavaScript 都需要在浏览器中运行。从历史上看，这给 JavaScript 框架带来了进化的压力，使其变得小巧、没有遗留代码，而不是扩展性强、功能丰富。

尽管我们仍然希望避免向浏览器发送大量 JavaScript，但近年来生态系统的巨大变化彻底改变了 JavaScript 框架的进化压力：客户端和服务器的统一。

如果我们在服务器上……渲染呢？

“在服务器上渲染模板？你说这能大大提高页面加载速度？谁能想到呢？”Rails 开发人员说着，眼珠子直往外冒。“你是说浏览器可以显示 HTML？

当然，从上世纪 90 年代的 cgi-bin 时代开始，网络开发人员就一直在服务器上呈现 HTML。但直到最近，在服务器上进行初始呈现的应用程序代码与在浏览器中呈现进一步交互和更新的任何独立但紧密耦合的逻辑之间一直存在阻抗失配问题1。即使双方都使用 JavaScript（例如，生成由 React 支持的页面的 EJS 服务器），相互冲突的运行时环境也会让它们之间的任何逻辑共享变得非常不顺畅。

这种摩擦导致人们普遍认为，每个网络应用都应该几乎完全由服务器渲染，客户端只使用很少的 JavaScript（Rails/Hotwire），或者几乎完全由客户端渲染，服务器主要提供 API（React SPAs）。这两种方法都有缺点，但都能奏效，最好选择其中一种。

至少在最近之前是这样！大约在 2021 年，关键的浏览器 API（尤其是fetch和import）在服务器上得到了很好的支持，包括在 node.js 和 Cloudflare 等边缘环境中。突然之间，在服务器和客户端之间共享库和 UI 组件从科学实验变成了主流。你可以拥有主要由服务器渲染的应用程序，但同样的代码可以在浏览器运行时即时更新用户界面。或者，应用程序主要由客户端渲染，但后来为了提高性能，也可以零散地转移到服务器上。现在，统一代码库这一圣杯已经成为可能。

这推动了一代 “元框架 ”的诞生，它们为现有的客户端 JavaScript 库添加了路由、数据获取和服务器端渲染功能。起初，这些框架本身还有些笨拙，但在许多情况下，它们已经发展到了官方默认的水平：

如果您想使用 React 构建新的应用程序或网站，我们建议您从框架入手。

React 文档鼓励人们在新项目中考虑 Next.js 或 React Router。

  1. Next.js 更受青睐，也许是我们最接近行业默认、包含电池的 JavaScript 框架的时候了。不过，它有点……古怪？而且最好在 Vercel 的无服务器平台上提供支持，这可能会让你对锁定或限制感到紧张。
  2. React Router（原名 Remix）也许更优雅，也更不依赖平台，但目前正在经历一些成长的烦恼，因为它正在经历最近的 React Router / Remix 合并。

不过，至少有三个原因让您不想选择这些框架中的一个：

  1. 这些框架与 React 深度集成，但独立开发。这意味着，如果你关注它们的开发，就会发现这些接缝处会产生额外的混乱2。
  2. 亚历克斯-罗素（Alex Russell）说，由于性能包袱，在 2025 年使用 React 会让你成为一个坏人。
  3. 这些框架支持 HTML 的服务器端渲染，但并不特别适合构建复杂的后台 API，如后台处理或 websockets。

枯燥乏味

好吧，没有一个明显的默认框架可供选择。那么我们该如何做出选择呢？

当我们选择采用任何新的依赖项时，无论是框架、库还是任何其他工具，我们都是在下注。我们在赌，赌这个新工具带来的速度收益不会因其维护负担而丧失。如果一个光鲜亮丽的框架过于复杂，或者维护不善，无法满足我们的需求，我们的日子就不好过了。

这就是为什么那些 “酷孩子 ”会选择枯燥、简单、维护良好的技术：你不会想成为第一个使用框架 X 遇到问题 Y 的团队，也不会想成为最后一个使用非品牌核反应堆的团队。

据我所知，这些是目前构建 JavaScript SaaS 应用程序时最接近枯燥乏味的框架选择：

  • 老派： 使用 Express API 后端的 React 单页面应用程序。这种方法屡试不爽，但由于忽略了十年来不断改进的工具，因此已经接近过时。
  • 以内容为中心的应用程序： Next.js可能很怪异、笨重，而且充满了Vercel元素，但如果你正在构建一个非常适合无服务器的电子商务或内容网站，那么它的普遍性可能会让你觉得它是一个无聊的选择。
  • 以后台为中心的应用程序： 如果您的应用需要复杂的后台处理或持久连接，您可以选择维护良好的 Express 后继产品（如 Fastify 或 NestJS）作为后台 API，并使用元框架之一来处理不太复杂的面向用户的部分。
  • Vercel 反对者 如果你无法忍受 Next.js，但又想使用渐进增强技术进行服务器端渲染，那么 React Router Framework 可能是最无聊的选择。希望现在 Remix 已经并入了非常流行的 React Router，它的寿命会更长。
  • React Objector： 如果你想在客户端和服务器之间共享组件，但又认为 React 已经过时，那么 Svelte 和 Vue 相对来说比较流行，而且足够简洁，你可以说它们很无聊。SvelteKit 是在 Svelte 中支持类似 Next 的 SSR 的一种好方法，但它已经开始影响 “无聊技术 ”的定义了3。
  • The Table-Flip： 现在是用 JavaScript 或 TypeScript 构建整个产品的最佳时机，但有些网站根本不需要 JavaScript。对于这些网站来说，Rails 或 Python FastAPI 等其他语言的成熟框架非常有吸引力。

所以，是的。框架还是太多了。

不过，我认为（这可能只是我与生俱来的乐观主义）情况已经有了很大改善。现在，JavaScript 生态系统正在构建框架，这些框架可以在客户端和服务器之间共享代码，但不会将大部分代码发送到浏览器，因此未来 10 年的发展应该不会像上一个 10 年那样具有破坏性。

如今，我们正享受着丰富的资源：适用于各种用例的强大工具。我是否希望它能安静下来，变得乏味一些？是的。

但它仍然非常棒。

感谢 Jenn Cooper 和 Brian Leroux 对这篇文章的反馈。

—

  1. 作为一个热爱打磨和愉悦的人，我非常关注这一点，但有时人们会问：”现在还需要客户端渲染做什么？我认为客户端渲染对于那些人们正在积极完成工作的产品来说是最重要的，在这些产品中，你需要乐观的更新、离线模式、快速工作流、实时协作以及让用户感到温暖的可爱小动画。
  2. 仅举两个最近的例子： Remix 一开始有自己的服务器组件模型，但 React 后来发布了 React Server Components，这大大改变了 React Router 框架的演进路径。此外，Next.js 15 在构建时假定 React 19 会比它的发布时间早得多，这导致 Next.js 15 依赖于预发布的 React 19，而就在今天，我听说这让一位 Next 开发人员泪流满面。无法控制你最重要的依赖关系是很困难的！
  3. “你可能会说：”实际上，Astro.js/Alpine.js/Hono.js/Preact.js/Lit.js/Solid.js/Nuxt.js/Flopsweat.js 算得上是无聊的技术，因为它很适合我的用例。对此，我会说：”嗯，其中有些框架看起来确实很不错。也许我应该快速设计一些原型…… “这时，我被吸引下了台

本文文字及图片出自 JavaScript Fatigue Strikes Back

你也许感兴趣的：

共有 47 条讨论

  1. 多年来，我一直回避网络编程。不仅仅是因为观察到的搅动，还因为你必须在多个并发堆栈之间游刃有余。我是在 CSS、html、JS 中解决这部分问题，还是在后端解决？浏览器引擎的状态如何？而且这很少是只选择其中一个具有不同语法和模型的堆栈，通常是至少两个堆栈按比例混合使用。

    但最近我在学习 Elixir LiveView。它并没有让这些问题完全消失，但从我的观察来看，它确实有所改善。

    回复

    1. Elixir 的触感非常舒适。当然，这完全是主观臆断。

      回复

  2. 作为一个最近审查了一个重构为 Next 的代码库的人，我认为有很多人们并没有真正考虑过的脚枪。我认为很多人认为只要打开服务器端渲染就能获得 “快速 ”应用程序。

    例如，将所有前端服务调用转移到后台，在等待这些调用解决的过程中，你的初始页面加载基本上会遇到瓶颈。首次绘制的时间绝对会缩短，而这是一个相当重要的感知性能指标，会影响交互性。

    我还发现，由于重构已经过时，转向 Next 的开发人员并不真正清楚如何在前端处理应用状态管理。过多的服务调用（请求已在其他组件中获取的数据）已经膨胀到了我从未见过的程度。由于所有这些调用都发生在后端，开发人员无法在任何现代浏览器的网络选项卡中看到这些请求，因此他们无法明显感觉到自己进行了过多的调用。

    因此，现在他们需要开始考虑缓存了，因为性能感觉差了很多。幸运的是，Vercel 可以向你推销这项服务–这又增加了一层复杂性，但却解决了他们的问题，而且他们还宣称 Next 是一个性能超强的框架。

    现在，我知道有一些非常有效的方法可以进行服务器端渲染，并正确使用 Next 中的新服务器组件和管理状态……但由于范式差异太大，我认为许多开发人员在尝试迁移到这种新的服务器端渲染框架时，会错过这一步，实际上会降低应用程序的性能。

    我可能是个老古板，但我确实认为这种 “新 ”的服务器端呈现方法增加了很多复杂性，却没有带来多少好处，但我仍然很高兴能更多地了解 Next，并理解使用这种风格的应用程序时的最佳实践。

    回复

  3. 我想知道为什么作者在写酷儿们选择旧技术时没有提到 PHP。对我来说，这是显而易见的：找个超便宜的虚拟主机，把 PHP、HTML 和前端 JS 放上去，然后就不用管服务器维护了。

    回复

    1. 他们认为每个人都在炒作 JS 后端。

      回复

      1. 关于 Webdev，我最不喜欢的事情之一就是 JS 似乎在某些话题上吸走了房间里所有的空气。

        这让人觉得这个行业就是为那些沉迷于 JS 的人准备的就业项目。）

        回复

    2. 也许是题外话，但当我想用 Laravel 做一个个人 PHP 项目时，也有类似的感觉。

      即使后台已经设置好了，前台仍然感觉要在 Blade、Livewire、Vue 和用 Inertia（？）粘合在一起的 React 中做出选择。然后，你还得在几种不同的身份验证系统中做出选择。不幸的是，我还想要应用程序支持，这就需要 React Native、Flutter 或其他东西，而 Laravel 文档似乎没有提到这些。

      当然，我们也可以用普通的 PHP 和 JS 从头开始，但这往往无法与完整的框架相提并论。

      回复

      1. Laravel 已经高度商业化，去年获得了 5700 万美元的风险投资。虽然它仍然是一个开源框架，但已经发展成为一个成熟的生态系统，拥有 Forge、Vapor 等官方服务，以及简化开发和部署的入门套件（Breeze、Jetstream）。这些工具都是可选的，但 Laravel 正在加大通过 Composer 安装裸机版本的难度，巧妙地将开发人员推向其生态系统。

        Laravel 不再仅仅是一个 PHP 框架，它现在类似于 Java Spring，是一个有主见、对企业友好的生态系统，一切都可以通过配置连接起来。它的重心已转向企业和团队，而不是个人或业余项目。

        对于那些更喜欢具有长期稳定性和较少商业依赖性的传统框架的人来说，Symfony 仍然是一个可靠的选择。

        相关主题：

        https://www.reddit.com/r/laravel/comments/1iyyxk4/laravel_is…

        https://www.reddit.com/r/PHP/comments/1j05wh1/laravel_is_goi…

        回复

      2. 我不明白你的意思。您只需使用 jwt 和任何您想要的前端即可。

        回复

        1. 我不确定 “选择你想要的前端 ”是否能帮助那些在选择前端时遇到困难的人。

          回复

    3. 在这方面我提到了 Ruby 和 Python，但 PHP 和 Laravel 在我看来也可以算作前端。也就是说，PHP 可能正接近 Java 所处的阶段，即它很好理解，但却被认为过时，以至于在招聘和留住人才方面造成摩擦。

      回复

  4. NestJS 可能是最接近 Rails 的 JS 框架。它也是由 Fastify 的创建者开发的 Platformatic。

    尽管如此，JS 中的依赖关系纠缠还是太疯狂了。这是 Platformatic 的依赖关系图：

    https://npmgraph.js.org/?q=platformatic#zoom=h

    目前还没有一个 JS 框架能解决所有问题，并且不依赖其他软件包。

    我不知道为什么 JS 开发人员历来对框架反感。也许这篇文章的作者是对的，这是因为要防止浏览器中的 JS 应用程序过于臃肿。

    无论如何，在后端使用 Node 10 年之后，我已经不再使用它了。

    回复

  5. 我发现，我在 JavaScript 方面遇到的绝大多数问题都与现代工具本身有关。我非常喜欢 ES5 新语言的改进，例如不必担心作用域/挂起问题、async/等待、fetch 比之前的简单多了。

    另一方面，工具往往就像一台 Rube Goldberg 机器的转发器、编译器等。有些信息是有文档记录的，有些则没有，要把所有东西都整合在一起并正确配置 IDE/编辑器需要耗费大量时间。

    TypeScript 可以很好，但我也遇到过与类型系统对抗的问题。

    回复

  6. 最近最喜欢的无聊技术是 ASP.NET w/ Blazor 服务器端渲染。.NET Core 运行时性能出色，DX 非常漂亮，EF Core 可以说是与 ActiveRecord 相媲美的持久性框架，而且一切似乎都能很好地整合在一起。我非常欣赏 ASP.NET 的设计者们毫无保留地从其他框架中复制他们喜欢的东西。你有 Spring 无处不在的 DI、Rails 风格的配置约定，Blazor 组件与 JS 组件非常相似。Auth 是可以合理集成的第一方模块。

    我离 JS 生态系统越远，Webdev 对我来说就越有趣。

    回复

    1. 我和你的经历非常相似（不过我还没有试用过 Blazor，请参阅我在本主题中的其他评论）。最近，我还根据 HN 上某人的推荐，阅读了 Keith Grant 撰写的 CSS in Depth 一书。在与 CSS 斗争了十多年之后，现在终于明白了一切。我可以完全按照自己的想法来布局页面了。有了服务器端渲染、漂亮的 CSS 和一些必要的 JS，Webdev 可以变得如此有趣和高效。

      回复

    2. 是啊，我也正从 Node 转向 dotnet。DX 与 VSCode 配合得非常好，而且 EF Core 确实是市场上最好的 ORM 之一。性能也非常棒。

      对于 API，我正在使用 FastEndpoints [1]，并且非常喜欢它。一旦 Minimal API 有了验证等功能，我可能最终会改用 Minimal API。

      [1] https://fast-endpoints.com/

      回复

  7. 我用 Asp.Net（在 linux 上）制作了至少 3 个供个人使用的网络应用程序（托管在我的家庭服务器上，只能在本地网络内访问），我可以说这是我一段时间以来最好的开发体验。它非常乏味，包括电池、性能和出色的文档。在简单的情况下，可以使用 Minimal API 进行非常简洁的设置，但也可以使用 Razor 页面或 MVC 支持更复杂的需求。

    我坚信，只是微软的声誉阻碍了它在企业环境之外的应用（这也是当之无愧的）。

    回复

    1. 有趣的是，我刚刚也写了同样的东西。每个人都在谈论 ASP.NET，因为它是 MS 的产品，或者与 JS 无关。它被低估了。

      回复

    2. ASP.NET 是一门伟大的语言，只是缺少大量的在线教程和培训课程，而 JS 生态系统却有大量的在线教程和培训课程。

      回复

  8. > 突然之间，在服务器和客户端之间共享库和用户界面组件从科学实验变成了主流。你可以拥有主要由服务器渲染的应用程序，但同样的代码可以在浏览器运行时即时更新用户界面。或者，应用程序主要由客户端渲染，但后来为了提高性能，也可以零散地转移到服务器上。现在，统一代码库这一圣杯已经成为可能。

    还记得 Meteor[0] 吗？

    > ……但有时人们会问：”如今还需要客户端渲染做什么？我认为，客户端渲染对于那些人们正在积极完成工作的产品来说最为重要，在这些产品中，你需要乐观更新、离线模式、快速工作流、实时协作，以及让用户感到温暖的可爱小动画。

    现实情况是，SPA 对前三者来说大多是祸根，对最后一项来说则没有必要，而且除了少数特定的工作流程外，很少需要实时协作。现在的建议是先从单体开始，我希望人们先从服务器渲染的用户界面开始。而不是为了重新实现（糟糕的）现有浏览器功能而加载多个库。当你看到简单的博客在没有 javascript 的情况下甚至无法显示文本时，你会感到沮丧。

    [0]: https://www.meteor.com/

    回复

  9. 我的职业生涯越深入，我的错误决定对我的打击就越大。

    至少对于浏览器中的 JS 来说，我觉得今天选择哪种框架/范式并不重要，重要的是你的选择会如何限制你未来的选择。如果你能预测未来，你就会选择维持时间最长的框架，但你做不到，所以你只需专注于最大化基于网络变化缓慢的部分（HTML/CSS、浏览器 API）构建的框架中的抽象，并试着考虑 5-7 年后它将如何集成为你所抱怨的 “遗留 ”应用。

    我听说一些最成功的公司都有传统应用程序。如果这样做会阻止你改变选择，而不会先拆掉所有东西，那么在前期就为所有未来问题做出完美选择似乎是错误的选择。

    回复

  10. 在厌倦了 JavaScript 之后，我正在考虑学习 Rails（或者甚至 Django）。

    对于那些使用 Rails 的人来说，它是否真的超级高效，速度是否真的不是问题？

    回复

    1. 它非常高效。它可以扩展 99% 的应用程序。有一些常见的问题会影响性能，主要与 ActiveRecord/DB 层有关。比如忽略 n+1 或不确保实际查询路径的索引到位。您可以将大部分开销卸载到后台工作、缓存等。你还可以投入更多资金来扩展后端服务器，但这并不是最便宜的堆栈。

      此外，sorbet/tapioca 也是静态类型的好工具。诚然，要获得适当的设置需要一些工作。它们也有局限性（不要指望达到 TypeScript 的水平），但这是值得的。我仅仅通过键入一个大型模型，就发现了几个潜伏多年的 bug（尽管它已经过彻底测试）。

      回复

    2. 对于没有客户端交互性的应用程序，我默认推荐 Django。如果你要做的事情可以在一个成熟的框架中完成，那么目前流行的工具就会让你感觉在工作效率上有一个数量级的损失。

      回复

    3. 它速度很快，但你需要转换到 rails 方式。他们已经解决了许多与粗糙应用程序相关的实施问题，如果你的数据库和用户界面只是由一些业务逻辑规则分开，你就可以很容易地得到一个可用的应用程序。

      回复

    4. 在就业方面，我会谨慎一些。至少在 21-22 年，仍有大量 2010 年代的 Rails 开发人员，空缺职位似乎更优先考虑使用 Rails 的 YoE。

      回复

    5. Rails 是一个伟大的框架，一直都是。对于大多数普通应用程序来说，Rails 的性能完全没问题。

      回复

    6. 老实说，PHP Laravel、Rails、ASP .NET Core、Django 都具有超高的生产力。这只是你用起来是否得心应手的问题。

      回复

  11. .NET能在一定程度上限制网络框架的数量，这一点很好。.NET曾有过令人遗憾的ASP.NET Web Forms，后来又修正为ASP.NET MVC（虽然很可靠，但在.NET core时代有太多的API变化），现在又推出了非常出色的Blazor框架，让你在服务器和客户端都能使用C#… 我希望它能获得更多的行业动力，微软也能继续投资于它。

    回复

  12. 从路由到测试，rails 中基本上所有的东西都是通过 activerecord 绑定在一起的，是不是因为缺乏类似的 activerecord？

    回复

    1. AdonisJS 自带 Lucid，这是一种使用 Active Record 模式的 ORM。https://docs.adonisjs.com/guides/database/lucid。

      回复

      1. 它的界面看起来很相似，但它是否带有生成路由、视图、测试等的所有精彩工具？

        回复

    2. JavaScript 有很多独立的 ORM，如 Drizzle、TypeORM，还有 Knex 这样的 sql 构建器，只要上网搜索一下就能找到很多。

      我认为 ActiveRecord 实际上是 Rails 中最薄弱的部分，在大型 Rails 应用程序中，最可怕、最难管理的代码就是模型和要做大量 Active Record 的东西。

      正如 DHH 所说，Rails 的好处在于，它不仅仅是将所有部分组合在一起的总和，而是一种 “omakase”。在构建自己的想法之前，并不需要先构建一个框架。这就是拥有一个坚实而完整的基础，使附加软件包能够在知道自己拥有坚实基础的情况下进行扩展。在语言中占据主导地位，让大多数东西都能努力与你合作。

      除了 React 之外，我认为 JS 中没有任何软件包能像 Rails 在 Ruby 中那样具有引力。

      回复

      1. 实际上，我并不是 ActiveRecord 的粉丝，我有点讨厌它。但它是 Rails 跳动的心脏。ORM 的主要功能是定义一个具有生命周期钩子和猴子修补功能的全局可引用模型，而 ORM 方面的功能几乎让人分心。如果没有模型来快速生成代码，基本上其他一切都会崩溃。您提到的附加软件包之所以运行良好，是因为有很多方法可以挂钩到 activerecord（其次是路由等）。

        比如，典型的路径是：1）添加 gem，2）代码生成，3）运行迁移，4）现在你有第三方代码来管理你的模型的子集。从认证到发送邮件，从异步任务工作者到编写审计日志，这种模式非常强大。

        回复

  13. RedwoodJS 似乎是目前 JavaScript 中 Rails 的最佳尝试，值得一看。

    此外还有 Adonis，我花在它身上的时间较少，而且至少它的社区似乎不太引人注目。

    还有其他一些同类软件，但我往往会忘记它们的名字。

    回复

    1. > RedwoodJS 似乎是目前 JavaScript 中 Rails 的最佳尝试，值得一看。

      Redwood/Adonis 并没有得到广泛应用，这一点很能说明问题。我感觉 JS 生态系统在概念层面上的发展总体上相当缓慢。后端开发仍与 express.js 密切相关，而在其他生态系统中，express.js 已被视为最基本的框架。

      回复

  14. 我知道我在重写帖子，但对于较大的后端来说，nestjs（加上/或 fastify）是我们现在的首选。它就像一辆有主见的快车，一直是我工作的动力。

    回复

    1. 我来自 express，刚刚看了一下 nestjs 文档，我很困惑，这怎么会是学习的动力呢？有主见 “并不是积极的，我不想记住新的 ”nestjs 做事方法”，而 express 就是直观的。javascripts 的问题在于它的 Dunning-Kruger’d 崇拜者开发者认为他们知道更好的做事方法，并开始乱扔垃圾。这就是框架垃圾的本质，因为你可以，所以到处扔垃圾。

      回复

  15. > 直到最近，在服务器上进行初始渲染的应用程序代码与在浏览器中进行进一步交互和更新的独立但紧密耦合的逻辑之间一直存在阻抗失配。

    当然，像所有明智的用户一样，我绝对鄙视 JavaScript，也无法忍受网络开发人员无缘无故地烧掉我的电池。但是，我想知道，我们现在是否已经接近成功了呢？也许可以发明一个框架，检测用户是否禁用了 JavaScript，并在服务器端完成所有 JavaScript 渲染工作？

    我想到那时，网络开发人员就可以尽情编写脚本了，而他们的雇主将承担动态生成大量内容的成本。(希望激励机制的改变能让他们更加谨慎，如果不能，我想我也不会太在意）。

    回复

  16. 我没有 “JavaScript 疲劳症”，我有的只是 “JavaScript 是垃圾堆里的火，React 是撒旦的后代 ”的日常博文疲劳症。

    JFC。

    回复

  17. JavaScript 框架的快速发展既是福也是祸。虽然 React Server Components 等创新技术有望提高性能，但它们也带来了令人难以承受的复杂性。开发人员如何在与时俱进的需求和 “JavaScript 疲劳症 ”的风险之间取得平衡？

    回复

    1. 我只是觉得与时俱进的必要性为零。新的框架可能会更好，但都是渐进式的，而不是根本性的。我通过关注 HN 来保持 “与时俱进”，当一个名字变得如此熟悉，以至于看起来根深蒂固时，我就会在下一个新建项目中尝试一下。

      不是每个人都能这样工作；这是我工作领域的副作用。但我选择这样做的部分原因是，我宁愿完成工作，也不愿追逐新事物。

      回复

      1. 我也是这么做的，通过在 HN 上闲逛来了解最新动态。当某个堆栈或概念成为主流或对我的职业生涯很重要时，我会用它做一个小型的个人项目。我并不想成为专家，我只想有足够多的接触机会，如果有必要，我可以在短时间内提高工作效率。我认为这是就业保险。

        回复

    1. Htmx 太棒了。我一直在用它和 flask 做一些小项目，我再也不想用 JS 了，你不能逼我。

      很想听听其他人的看法……它有什么问题？

      回复

发表回复

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