原文：x-templ/
编译|苏米
出品| CSDN（ID：）
以下为译文：
自从今年尝试使用Go+HTMX（前端库，用于简化基于HTML的动态交互开发）+Templ（基于Go的模板引擎，专注于简化Web应用的开发）来完成我个人的一些项目结束后，我决定放弃在任何个人项目中使用 React。
事实上，放弃 React 并转向 HTMX 并不是一个孤立的案例。在HTMX的官网论坛上，你会发现这种情况也很常见，而且各有各的原因，但很少有人提到依赖管理疲劳的问题。 。
什么是依赖管理疲劳？
最近，当我使用React()开发个人项目时，我发现我花了太多时间处理React包的依赖更新。我努力将我的软件包更新到最新版本，但经常发现其 API 发生重大更改，导致我花时间重构我的代码。
我想要跟上这些依赖项更新的原因是因为我的 Web 应用程序部署在可公开访问的 EC2 实例上，并且我希望避免潜在的漏洞。
真的有必要进行新的主要版本更新吗？
有一些包在这个问题上是“大问题”，例如 React 路由包（Query）和我用来从后端获取、缓存和管理状态的库（Query）。截至2024年12月，已更新至主要版本3，Query已更新至主要版本5。
我不会将这些包用于小的功能或样式调整，它们是我的 Web 应用程序正常运行的基础。如果它们出现问题，我的 Web 应用程序就会崩溃，例如无法从后端获取数据或路由功能失败。在这种情况下，就没有什么“渐进增强”可言了。
当我第一次遇到我的应用程序由于其中一个 React 库的主要版本更新而崩溃时，我没有多想就重构了代码。
但当第二次发生的时候，我感觉很奇怪，开始反思：
结论是什么？
经过思考，我得出结论：
我实在是没时间去处理这些事情……
这就引出了本文的一个核心问题：为什么这是一个值得关注的大问题？
问题的关键，至少对我来说，是这样的：我没有很多空闲时间。如果我最终找到一些时间来处理自己的编程项目，我不想因为依赖库的主要版本更新而浪费时间重构代码。我想利用时间来开发新功能或启动新项目。
如果您正在为客户开发产品并且可以收取后续维护费用，请随意使用不稳定的依赖项。这样做甚至可能对您的经济利益更好。但如果你想开发一款上线后需要尽可能少维护的产品，那么我会尽量远离整个JS生态。
选择 Go + HTMX +
这也是我以后自己的项目只会使用Go+HTMX+Templ的原因。也许这只是一个例外，但我从事的 Go 项目让我能够专注于功能开发，而不会忽视依赖项和安全更新。 Go的标准库和语言规范一直保持着非常高的稳定性。
Web生态之战
这篇文章发表后，也在HN上引起热议。
有网友表示：
我对作者的感情深有共鸣。 2019 年左右，我彻底放弃了 React 及相关生态。此后，我使用 Actix、Tera、HTMX 等相对精益的技术栈构建了一批 Web 应用，这些应用在长期可维护性方面表现良好，吸引了很多人关注。忠实的用户追随者。
上周，我用了不到 24 小时的时间将一个新想法构建成一个 Web 应用程序并将其发布给内测用户，然后在不到 7 天的时间内推出了公测版本。一切都很顺利，没有任何问题或担忧。当然，我效率提升的部分原因可能是我多年来通过多个项目深刻掌握了这个技术栈的方方面面。但需要强调的是，如果我一直像作者所说的那样被“依赖管理疲劳”所拖累，我可能永远无法达到今天熟练使用这些工具的水平。
不过，也有人认为现在情况已经有所好转：
该生态系统的大部分设计可以追溯到浏览器体验很糟糕的时代。当时 DOM 更新速度非常慢（因此需要引入 DOM），不同浏览器之间出现各种奇怪的差异，浏览器的内置工具也非常有限，比如没有 Web、客户端-侧存储、加密、组件等功能。因此，为了弥补当时浏览器功能的缺陷，开发者需要引入成百上千个依赖包。但现在，浏览器的能力已经有了很大的提升，这些东西大部分已经变得没有必要了。
您对此有何看法？
