Redis之父说：现代前端是个骗局

1999年，你写三个 .html 文件、撒一点 .css、再用几行 JavaScript 操纵表单。一个能被全世界访问的网站就建成了。源代码和浏览器里看到的东西，几乎一模一样。

二十七年之后，同样的任务变成了一场军备竞赛。

TypeScript → TSX → JSX → Vite → Webpack → Tree Shaking → Babel → PostCSS → Polyfills。每一层都在解决上一层制造的问题。你写的源代码，和最终在浏览器里跑的东西，已经是两个物种。

Redis 之父 antirez（Salvatore Sanfilippo）看到了这件事。他在 Hacker News 上发了一条评论，获得了最高赞。他说了一句让很多人不舒服的话：

"大型框架是被大公司推给用户群的。它们是'大公司设计'的产物，后来才变成了行业常态。这就像让地球上每个网站都跑在 Kubernetes 上一样可笑。"

1. 大厂的组织架构，绑架了全行业

antirez 的核心判断是：现代前端的复杂性，根源不在技术需求，而在组织架构。

大厂有两个硬性需求：

第一，彻底隔离前后端。因为他们的组织架构就是这么划分的——前端团队、后端团队、DevOps 团队，各管一摊。API 边界必须清晰，数据转换必须发生在客户端，路由必须在前端解决。这些不是"更好的架构"，是"人事结构在技术栈上的投影"。

第二，极度标准化。这样他们可以轻松地招聘新人、开除旧人。一个 React 开发者跳槽到另一个 React 项目，学习成本趋近于零。这是人力资源管理的优化，不是用户体验的优化。

这两个目标，都与"构建一个优秀的 Web 应用"背道而驰。antirez 说得直白：

"讽刺的是，前端开发者自己深受其害。他们被迫不断地学习新的方式去实现同一个按钮、同一个分页。而且，如果他们足够聪明，他们会意识到，在大多数情况下，他们根本不知道'编程'到底是什么。"

这话刺耳。但想想：一个能熟练背诵 React 生命周期、却不知道 JavaScript 原型链的人，是不是确实"懂框架，不懂语言"？

2. 为一个按钮，引入整个宇宙

原帖作者详细拆解了现代 SPA 的编译之旅。你写一行 <button>，背后发生了什么？

TypeScript 代码先被转译成 JavaScript，因为浏览器不认识 TS。TSX 文件被转换成 React.createElement() 调用。成百上千个 .js 文件被打包成一个或几个文件，否则引发网络风暴。打包过程中还要 Tree Shaking，删掉没用到的代码。然后 Minification，变量名缩短、空格删掉。ESNext 语法被 Babel 降级成 ES5，因为还有人在用旧版浏览器。Post CSS 加上各种 -webkit-、-moz- 前缀。

走完这一整套，你才能在浏览器里看到一个按钮。

1999年，写按钮只需要 <button>。2026年，需要一整条编译管线。这个按钮的"复杂度成本"增长了多少倍？没人算过。但 antirez 暗示了一个判断：这些复杂性中的大部分，不是商业需求驱动的，是大厂内部流程的外溢。

3. HTMX：回到1999年

在这场对 SPA 的"集体围剿"中，一个名字被反复提及：HTMX。

它不是新技术。恰恰相反，它是一种"文艺复兴"。核心思想一句话：让后端直接返回 HTML。

<button hx-get="/news" hx-target="#news-container">
  加载最新新闻
</button>
<div id="news-container"></div>

点击按钮，HTMX 自动向 /news 发起请求，用返回的 HTML 片段替换 #news-container 的内容。没有前端路由，没有状态管理，没有虚拟 DOM。前端的复杂性，被几个 HTML 属性消灭了。

对于那些被 React/Vue 的复杂性折磨的开发者来说，这简直是天降福音。antirez 显然站在这一边。他写的 Redis 本身就是 C 语言的一个极简主义杰作——一个数据结构服务器，代码清晰到可以在飞机上读完。

但 HTMX 也有反对者。

4. 复杂性没有消失，只是搬家

一位拥有 10 年经验的全栈开发者说："你以为用了 HTMX 就没有复杂性了？你只是把复杂性从前端转移到了后端。"

这句话切中要害。现代 Web 应用本质上就是两个生活在不同环境的应用（前端和后端）。错误处理、用户体验、性能、可维护性——这些问题的复杂性不会因为"后端返回 HTML"而消失。它们只是换了一个地方发生。

另一位开发者更直接："对于需要深度交互、复杂状态同步的应用（在线文档、画图工具），HTMX 那套简单的'换 HTML'模式，很快就会捉襟见肘。"

这是真的。Google Docs 不是用 HTMX 写的。Figma 也不是。这些应用需要的状态同步粒度，远超"替换一个 HTML 片段"的能力。

所以 HTMX 不是银弹。它适合一类问题：内容展示型网站、管理后台、表单驱动的应用。但它不适合另一类：实时协作、复杂状态、深度交互。把 HTMX 当成万能药，和把 React 当成万能药，是同一个错误。

5. antirez 没给的答案

antirez 没有给出"最终答案"。他不需要。他给出的是三个反思方向：

第一，警惕大厂的"最佳实践"。那往往只是解决他们自己内部组织架构问题的"特制药"。Kubernetes 适合 Google，不等于适合你的博客。React 适合 Facebook，不等于适合你的电商首页。

第二，重新审视"分离"的代价。前后端分离带来了职责清晰，也带来了巨大的通信成本和复杂性。在很多场景下，一个由后端主导的简单架构，远比拆分的微服务架构更高效。分离不是目的，交付才是。

第三，拥抱多样性。React 的组件化和 HTMX 的超媒体，只是工具箱里的不同工具。成熟的架构师懂得在不同场景做取舍，而不是陷入"非黑即白"的宗教战争。

6. 我的判断

antirez 的吐槽有价值，但也有局限。

他的局限在于：Redis 是一个服务端软件，不是用户界面。他对前端复杂性的体验，主要来自"看别人写前端"，而不是"自己写一个在线文档编辑器"。他的极简主义美学在服务端领域是对的，但在用户界面领域可能不够。

但他的核心判断是对的：现代前端的复杂性中，有相当大一部分是"历史偶然"而非"本质必然"。大厂的组织架构、标准化需求、招聘策略，确实把整个行业的技术栈推到了过度复杂的方向。很多网站不需要 SPA，不需要虚拟 DOM，不需要状态管理——它们只是需要一个能点击的按钮和几页内容。用 React 写这些，确实像"让地球上每个网站都跑在 Kubernetes 上"。

关键问题不是"React 好还是 HTMX 好"。关键问题是：你的业务的复杂性，到底在哪里？ 如果复杂性在用户交互和状态同步，React 可能是对的。如果复杂性在数据处理和业务逻辑，HTMX 加后端可能是对的。最糟糕的选择是：用 React 写一个本质上不需要 React 的网站，因为"这是行业标准"。

antirez 的帖子底下有一条评论让我印象很深："作为一个与 JS/TS 相依为命的人，我无数次想过能不能用 Go + HTMX 来简化这一切。但说实话，我至今没找到一个能比现有 SPA 栈哪怕好一点点的方案。"

这说明什么？说明前端复杂性的"解药"还不存在。HTMX 是症状缓解，不是根治。真正的根治，可能需要一种新的范式——不是"回到1999年"，也不是"在2026年的工具链上继续堆"。而是找到一种既能表达复杂交互，又不引入过度工具链的方式。

那可能是什么？我不知道。antirez 也不知道。但他至少提醒我们一件事：停下来，看一眼，问一句——我们费尽心机建立的这套复杂体系，到底是在解决真正的商业问题，还是在制造更多的问题？

能问出这个问题的人，已经比大多数人清醒了。

参考链接

• 《现代前端的复杂性：是本质必然还是历史偶然？》，Igor Šarčević，binaryigor.com，2026
• antirez (Salvatore Sanfilippo) 在 Hacker News 的评论，news.ycombinator.com/item?id=47824051，2026
• HTMX 文档：htmx.org
• Tony Bai 的翻译与解读：tonybai.com/2026/05/29/redis-creator-slams-modern-frontend-complexity

#前端复杂度 #HTMX #React #SPA #Redis #antirez #智柴