今年 7 月，微软宣布不再在 Edge 浏览器中使用 React，理由是其效率不高。这一决定引发了广泛讨论，尤其是在开发者群体中。随着时间的推移，越来越多的开发者在自己项目中尝试其他技术后，也表达了类似的观点。他们认为，React 生态系统中频繁的更新和破坏性变化，常常让开发者感到挫败，并浪费大量时间。从 React 最初以简单、灵活的姿态出现在开发者眼前，到如今由于版本更新和依赖管理带来的困扰，越来越多的开发者开始重新审视这个曾经风靡一时的框架。那么，React 真的已经不再适合现代开发了吗？
原文：https://blog.erodriguez.de/dependency-management-fatigue-or-why-i-forever-ditched-react-for-go-htmx-templ/
编译 | 苏宓
出品 | CSDN（ID：CSDNnews）
以下为译文：
自从我在今年尝试用 Go+HTMX（前端库，用来简化基于 HTML 的动态交互开发）+Templ（基于 Go 的模板引擎，专注于简化 Web 应用的开发） 这几种技术来完成自己的一些个人项目之后，我决定放弃在任何个人项目中使用 React。
实际上，抛弃 React 转向 HTMX 也并非个例，在 HTMX 的官网论坛上，你会发现这种情况也很常见，而且各有各的理由，但是他们中却很少有人提到依赖管理疲劳这个问题。
什么是依赖管理疲劳？
最近这段时间，我在用 React 开发个人项目时（https://github.com/erodrigufer/catDict），发现自己花了太多时间在处理 React 包的依赖更新上。我辛辛苦苦将我的软件包更新到最新版本，却经常发现它们的 API 出现了破坏性更改，导致我不得不投入时间重构代码。
我之所以想跟上这些依赖项更新的步伐，是因为我的 Web 应用当时部署在一个公开访问的 EC2 实例上，我希望避免潜在的漏洞。
新的主版本更新真的必要吗？
在这个问题上，有些包是“问题大户”，比如一个 React 路由包（wouter）和一个我用来从后端获取、缓存和管理状态的库（TanStack Query）。截至 2024 年 12 月，wouter 已经更新到了主版本 3，而 TanStack Query 则更新到了主版本 5。
我使用这些包并不是为了实现小功能或样式调整的，它们是我的 Web 应用正常运行的基础。如果它们出了问题，我的 Web 应用就会直接崩溃，比如无法从后端获取数据或路由功能失效。这种情况下，没有任何“渐进增强”可言。
在我第一次遇到因为其中一个 React 库的主版本更新导致我的应用崩溃时，我没有多想，直接重构了代码。
但当第二次发生时，我觉得很奇怪，于是开始反思：
我的 Web 应用从这些主版本更新中获得了什么实际好处（除了可能的安全补丁）？
在一个 React Web 应用中，真的有必要把一个核心组件的 API 破坏性地更改五次吗？
我花在这上面的时间值不值？这些时间本可以用来开发新功能或其他产品。
结论是什么？
经过思考，我得出的结论是：
我的应用没有获得任何额外好处。这些包的功能已经完全够用了。
至于是否有必要频繁破坏 API，我不是这些库的核心维护者，所以无法完全回答。但从用户的角度来看，我会说：没必要。API 设计需要深思熟虑，发布的功能应该是计划长期维护的，不要随意重命名导出对象。
时间的价值：我非常感谢开源维护者的付出，他们有权自由管理自己的项目（我自己也会这么做）。但如果目标是维持一个快乐的用户群体，我觉得“珍惜用户宝贵的时间”应该是优先事项之一。
我真的没时间处理这些事情……
这就引出了本文的一个核心问题：为什么这会是值得关注的大问题？
至少对我来说，问题的关键是：我的空闲时间本来就不多。如果好不容易找到一点时间来做自己的编程项目，我不想浪费在因依赖库的主版本更新而重构代码上。我想把时间用来开发新功能，或者启动新项目。
如果你是在为客户开发产品，并且可以通过后续的维护收费，那请随意，尽管去用那些不稳定的依赖库。这样做可能甚至对你的经济利益更有利。但如果你想开发一个上线后需要尽量少维护的产品，那我会尽量远离整个 JS 生态。
Go + HTMX + Templ 的选择
这也是为什么我以后只会用 Go + HTMX + Templ 来做自己项目的原因。或许这只是个例，但我参与的 Go 项目让我能专注于功能开发，同时也不会忽视依赖和安全更新。Go 的标准库和语言规范一直保持着非常高的稳定性。
Web 生态之争
这篇文章一经发布之后，也在 HN 上引起了激烈的讨论。
有网友 bsnnkv 表示：
我对作者的感受非常有共鸣。我大概在 2019 年左右彻底放弃了 React 及相关生态。从那以后，我用一个相对精简的技术栈——Actix、Tera 和 HTMX，构建了许多 Web 应用，这些应用在长期的可维护性上表现良好，还吸引了一批忠实用户。
上周，我用了不到 24 小时将一个新想法做成了 Web 应用并发布给封闭测试用户，随后在不到 7 天内上线了公开测试版，一切顺利，没有遇到问题或引发关注。当然，我效率提升的一部分原因可能是这些年通过多个项目深入掌握了这套技术栈的方方面面。但需要强调的是，如果我总是像作者提到的那样被“依赖管理疲劳”拖累，可能永远无法达到如今对这些工具的熟练程度。
不过，也有人认为，现在这种情况已经有了良好的改善：
很多 JavaScript 生态系统的设计都可以追溯到一个浏览器体验很糟糕的年代。那时候，DOM 更新速度很慢（因此需要引入 Shadow DOM），不同浏览器之间的各种奇怪差异层出不穷，而且浏览器内置的工具也非常有限，比如没有 Web Workers、客户端存储、加密、Canvas、组件等功能。因此，当时为了补全浏览器功能的缺陷，开发者需要引入成百上千的依赖包。但现在，浏览器的能力已经大大提升，这些东西大多已经变得不再必要了。
对此，你有什么样的看法？
限时福利来了！
勿再“浮沙筑高台”
用扎实的 C++ 技术为你的职业发展奠定坚实基础
加入「C++ 大师系列精品课」
带你踏上一条通往技术巅峰的学习之旅！
热门跟贴