内容摘要

很多程序员把简单问题复杂化，用昂贵的 React 框架去写简单的搜索框，结果网页又慢又难维护。本文通过一个真实案例告诉你：回归最基础的 HTML 逻辑（使用 HTMX），不仅能让网页加载速度提升 5 倍，还能让你少写 90% 的垃圾代码，准时下班不再是梦。

一个扎心的真实故事

前阵子我差点因为写代码把自己写“崩”了。

我们团队花了 6 个星期，用最流行的 React 技术给客户磨了一个产品看板。结果呢？一个刚入行的大学生，用我听都没听过的 HTMX，花了一个下午就把这玩意儿重写了。

最气人的是，他的版本比我的快得多，客户看了一眼就直接选了他的方案。那感觉，就像我开着顶级跑车在堵车，人家骑着共享单车嗖地一下就过去了。

为什么 React 会让简单的事情变复杂？

咱们就拿网页上最常见的“搜索框”来举例。你打个字，下面出结果，就这么点事儿。

React 的做法：搬起石头砸自己的脚

在 React 里，为了实现这个功能，我得：

• 先定义一堆“状态”（State）来盯着用户打了什么字。
• 写个“副作用”（Effect）去管怎么发请求。
• 处理“加载中”的小圈圈。
• 最后还得把服务器吐回来的 JSON 数据，手动一行行塞进网页里。

结果： 我写了 4 小时代码，给网页增加了 142KB 的重量，还往电脑里下载了 47 个莫名其妙的依赖包。

HTMX 的做法：简单到让人怀疑人生

那个大学生只在 HTML 里加了几行“指令”：

<input  type="text"  name="q"  hx-get="/api/search"  hx-trigger="keyup changed delay:300ms"  hx-target="#results"><div id="results"></div>

我问他：“剩下的代码呢？状态管理呢？” 他回我：“服务器直接把渲染好的网页片段发过来，浏览器接住直接显就行了，要什么代码？”

为什么 HTMX 这么快？（小白也能看懂）

我们可以把网页显示的过程想象成点外卖。

• React 的模式（点食材）：你给饭店打电话，饭店给你送来一堆生肉、生菜（JSON 数据）。你得自己在家洗菜、切菜、炒菜（JavaScript 解析数据），折腾半天才能吃上饭。
• HTMX 的模式（点成品）：你给饭店打电话，饭店直接把炒好的热菜（HTML 网页片段）送过来。你打开盒子直接就能吃（浏览器直接显示）。

你说哪个快？

数据对比：不看不知道，一看吓一跳

我用专业工具测了一下两个版本的性能：

指标 React 版本 HTMX 版本 打开网页的速度 1.8 秒 0.4 秒（快了 4 倍多！） 能点按钮的时间 3.2 秒 0.6 秒（几乎秒开！） 代码文件的大小 412KB 14KB（轻如鸿毛！）

HTMX 版网页加载完的时候，React 版的代码还在后台吭哧吭哧地解析呢。

我们是不是走错路了？

这几年，前端圈子有个坏习惯：不管什么项目，先上一套 React/Vue 全家桶再说。

结果呢？

1. 学不动了：新手得学一堆什么 Hooks、Context、Server Components，还没学会，下个月又出新的了。
2. 修不完的 Bug：我常在周五晚上加班，就为了查为什么 React 网页突然变白屏。而用 HTMX 的同事，周五下午 4:45 准时关机走人。

HTMX 的“魔法”其实就是回归常识

HTMX 只有 5 个常用的关键词，只要你会写基本的网页标签，半天就能上手。

• hx-get：去哪儿拿数据？
• hx-trigger：什么时候去拿？（比如松开键盘时）
• hx-target：拿回来的东西放哪儿？

避坑指南：HTMX 是万能的吗？

虽然我吹了半天 HTMX，但也要说句实话：它不是用来取代一切的。

• 什么时候用 HTMX？ 如果你的网页大多是：搜索、填表单、点按钮刷新个列表、改个账号设置。用 HTMX，你会爽到飞起，代码少、速度快。
• 什么时候还得用 React？ 如果你在做一个像 Google Doc 那样多人实时编辑的东西，或者像复杂的地图、3D 家具预览，这种需要极其精细控制的地方，React 依然是王者。

但问题是： 我们 90% 的普通网页，根本就不需要那些花里胡哨的复杂架构。

最后想说的话

上周二，我亲手删掉了那 3,847 行 React 代码。 网页变快了。 Bug 变少了。 我终于能在天黑之前下班，回家陪陪家人了。

我们总是追求最先进、最时髦的技术，却忘了做网页的初衷：简单、好用、快。