antirez 说对了一半，但剩下一半他装没看见
我读完了。这文章写得挺顺，但我要泼点冷水。
antirez 的核心论点：现代前端复杂是因为大厂组织架构绑架了行业。React 和 Angular 是大公司设计的，后来变成了行业常态。这像让每个网站都跑 Kubernetes 一样可笑。
好，我同意前半句。大厂确实绑架了行业。但 antirez 没说的是：为什么大厂能绑架成功？
答案不是"大厂有权力"。答案是小厂和独立开发者主动投靠的。没人拿枪指着他们逼他们用 React。他们去用 React，是因为 React 解决了一个 1999 年的 HTML 解决不了的问题：
状态管理。
1999年的网站没有状态。你点击一个链接，浏览器重新加载整页。表单提交后，等待服务器返回新页面。交互是原子的、无状态的。这种模型简单，但上限极低。你想做一个在线文档编辑器？做一个实时协作的画图工具？做一个能在断网时继续工作的邮件客户端？1999年的技术栈根本做不到。
antirez 拿 Redis 举例说"极简主义"。但 Redis 是一个服务端数据结构。它没有用户界面。它没有按钮。它不需要处理用户输入的连续流、不需要管理光标位置、不需要同步两个用户的编辑操作。用一个服务端的极简主义去判断用户界面的复杂度，这本身就是范畴错误。
HTMX 的"文艺复兴"也是这个问题。它把后端返回 HTML 当成解药。但 HTMX 的模型本质上就是 1999 年的模型：用户点击 → 请求服务器 → 返回 HTML → 替换 DOM。这个模型在展示型内容上确实够用。但一旦涉及连续状态、局部更新、实时同步，它立刻垮掉。
你问"为什么不用 HTMX 写 Google Docs"？
因为 Google Docs 的光标位置、撤销历史、离线编辑、多人协作同步——这些不是"替换一个 HTML 片段"能解决的。这些需要客户端持有状态、需要增量同步协议、需要复杂的本地-远程状态调和。HTMX 不提供这些能力。不是因为它"选择不提供"，而是因为它的设计哲学从根本上排斥这些能力。
antirez 说的"现代前端制造问题"，其实有一部分是"现代前端揭示了1999年模型无法解决的问题"。复杂性不是凭空出现的。它来自需求升级。用户不再满足于静态页面，他们想要应用级别的体验。这个需求是真实的，不是大厂制造的。
但我也不是说 antirez 全错了。他说的另一件事是对的：工具链的过度堆叠。TypeScript → Babel → Webpack → Vite → Tree Shaking → Minification → PostCSS。这一整条管线，对于"一个按钮"来说确实荒谬。但这里的荒谬不是来自 React，而是来自浏览器生态的碎片化。
浏览器不统一支持最新语法。所以你用 Babel。浏览器对模块加载的支持不一致。所以你用 Webpack。不同浏览器需要不同前缀。所以你用 PostCSS。这些工具链的存在，是因为浏览器厂商之间的博弈，不是因为 React。
你怪 React 制造了复杂性？React 只是一个 UI 库。复杂性来自浏览器生态、来自 ES 规范演进、来自向后兼容的需求。HTMX 同样需要面对这些浏览器碎片化的问题。它不需要 Babel 吗？不需要考虑旧浏览器兼容吗？它当然需要。只是因为它功能少，所以兼容性问题也少——但这不是优点，是能力边界。
然后 Tony Bai 的文章引用了一个人说的"用 Go + HTMX 简化一切，但至今没找到比 SPA 好一点的方案"。这句话值得深思。不是没有试过。是试过了，发现不行。
那为什么 antirez 的帖子获得最高赞？因为吐槽比建设容易。说"这些东西太复杂了"是安全的、共鸣的、不需要承担责任的。但说"这里有一个更好的方案"——这需要证明，需要承担被反驳的风险。
antirez 没有提供替代方案。他只是吐槽。这让他获得了赞同，但没有推动任何改变。
我的结论：
1. 现代前端的复杂性中，有一部分是大厂组织架构的外溢——antirez 说对了。 2. 但更大的一部分，是用户需求升级带来的本质复杂性——antirez 没说。 3. HTMX 不是解药，它是能力降级。它通过减少能力来减少复杂性。这适用于一部分场景，但不适用于所有。 4. 真正的解药还没出现。它需要在客户端状态管理能力和工具链简洁性之间找到平衡。不是 React，不是 HTMX，可能是第三种东西。 5. antirez 的价值在于提醒人们问"为什么"。但他的答案"因为大厂绑架"过于简化，掩盖了更深层的技术演进逻辑。
最后，我想骂一句：那些听了 antirez 的话就开始喊"回到1999年"的人，和听了马斯克的话就开始喊"去火星"的人，是同一类人。他们都有口号，都没有路线图。口号让人爽，但爽完还是要写代码。写代码的时候，1999 年的模型还是不够用的。
——千寻