X记录空间去年我花了四十分钟搭建一个用于内部管理后台的 React 项目。只是一些样板代码：Vite 配置、ESLint 设置、Tailwind 集成、React Router，还有 TanStack Query，因为有人在 Twitter 上说这是现在处理服务器状态的正确方法。当时我一行实际的应用逻辑都没写，就已经打开了十二个文件。
仪表盘需要列出数据库中的记录，允许用户筛选记录并更新状态字段。就三件事。就这些。
从那以后，我一直在思考那一刻。倒不是因为 React 本身有什么问题，而是因为整个经历让我问了一个我或许应该早点问的问题：我究竟在解决什么问题？我的技术栈是否与这个问题相匹配？
严格来说，HTMX 自 2020 年就已存在。Carson Gross 基于一些更早的理念构建了它——intercooler.js、超媒体以及 REST 的正确运作方式。但直到最近一年半左右，它才开始真正出现在生产代码库中，而不再局限于业余项目和博客文章。HTMX 的 GitHub 代码库的star 数已突破 4 万。2024年的 JS 现状调查显示了一个奇怪但真实的现象：开发者在 React 旁边标记“不会再次使用”的选项越来越多，而 React 的使用率却依然很高。人们仍在使用它，但显然热情正在逐渐消退。
HTML 的工作原理其实很简单，一句话就能解释清楚：它允许 HTML 元素发起 HTTP 请求，并根据响应交换页面的不同部分。就这么简单。没有虚拟 DOM，没有组件生命周期，没有客户端路由，也不需要任何状态管理库。你只需hx-get="/search"在输入框中输入内容，hx-trigger="keyup changed delay:300ms"结果对应的 div 就会更新。HTML 本身就是状态。服务器渲染 HTML。搞定！
对于很多使用场景——无论是枯燥乏味的还是富有成效的——这真的就足够了。
Python 的介入几乎是水到渠成。Django 和 FastAPI 都非常擅长快速渲染 HTML 片段。Django 的模板引擎被低估了。FastAPI 搭配 Jinja2 的速度足够快，足以应对小型团队可能遇到的绝大多数流量水平，你几乎无需考虑其他因素。你从端点返回一个 HTML 片段，HTML 将其添加到 DOM 中，用户就能看到相应的变化。无需 JSON 序列化，无需客户端反序列化，也无需 React 重新渲染。服务器只需完成其应有的任务：处理数据，决定 UI 的显示方式，然后将其发送出去。
Miguel Grinberg 在他的 Flask-HTML 教程中对这种模式做了很好的阐述，其核心观点几乎是枯燥乏味的：Web 应用采用服务器端渲染已经长达十五年之久，而且运行良好。SPA 时代确实解决了一些实际问题，但也引入了大量不必要的复杂性。
我想客观地说明一下，因为关于 React 的讨论很容易跑题。React 本身并不差。它在它最初设计的领域表现非常出色。当你需要丰富的客户端交互功能时——例如协作编辑、复杂的实时界面，或者类似 Figma 或 Notion 的应用——组件模型、单向数据流和客户端渲染方式就显得尤为重要。它的生态系统确实令人印象深刻。Next.js 解决了实际的部署难题。React 服务器组件，一旦你克服了最初对它们概念的困惑，就会发现它们确实是一种值得理解的架构理念。
但大多数应用并非 Figma。大多数应用都是带有筛选功能的 CRUD 操作。大多数内部工具都是表单、表格和仪表盘。大多数自由职业项目都是电商网站和预约系统。而对于所有这些应用，React 技术栈都要求你承担大量对最终用户毫无益处的功能。
关于 JavaScript 疲劳的讨论由来已久——Jose Aguinaga 在 2016 年发表的这篇文章在八年前还颇具讽刺意味，因为它一针见血。讽刺的是，到了 2026 年，它依然适用，只是库的名称有所改变。打包工具变了。状态管理从 Redux 演变为 Zustand，再到 Jotai，以及之后出现的各种工具。React 引入了服务器组件，导致一半的现有教程都失效了。要正确搭建一个 React 项目——甚至不需要编写应用程序逻辑，仅仅是搭建框架——所需的元知识量对于很多团队来说实在难以接受。
在这里，我想谈谈在这些讨论中很少被提及的一点，那就是南亚开发者的具体情况。
许多关于前端框架的讨论都发生在拥有高速网络、高端电脑的美国/欧洲开发者的视角下，而他们的客户只要界面美观，对性能并不在意。这种背景塑造了默认设置。当 Vercel 或 Netlify 的博客文章讨论包大小和核心 Web 指标时，他们通常是在为那些认为 300kb 的 JS 包只是小麻烦的受众写作。但在巴基斯坦——卡拉奇、拉合尔、海得拉巴以及其他一些小城市——这可不是小麻烦。二线城市的移动数据用户正在等待你的单页应用（SPA）加载完毕，而这在用户体验中显而易见。
这里的自由职业者大多在 Upwork 和 Fiverr 上接活。很多项目都是为小型企业开发后台管理面板、为本地公司开发人力资源工具以及基础库存管理系统。预算不高，时间也很紧。如果一位巴基斯坦开发者能够用 Django + HTML 在两三天内交付一个功能齐全的后台管理面板，因为无需设计 API 层、管理客户端状态或单独配置身份验证令牌流程——这无疑是巨大的生产力优势。
我跟一些在信德省和旁遮普省的HITEC、COMSATS以及类似大学做毕业设计的学生聊过。说实话，React技术栈对那些还在摸索async/await的学生来说确实有点难。看着有人下午就搞懂HTML，晚上就能做出能用的东西——这可不是件容易的事。这种既能降低入门门槛又不牺牲功能的科技，确实值得称道。
本地的SaaS思维模式也截然不同。在卡拉奇，当有人开发他们的第一个B2B软件产品时，他们考虑的是如何快速获得付费客户，而不是他们的架构能否扩展到千万用户规模。Python搭配Django，就能在一个软件包中提供ORM、管理面板、身份验证和模板系统。再加上HTML，你就能获得响应式UI，而无需单独部署前端、配置CORS或处理API版本控制等繁琐的工作。对于单人创始人或两人团队来说，这种简洁性价值连城。
随着时间的推移，我越来越清楚地认识到哪些情况下我会真正选择 Python + HTMX。
内部工具显然是最佳选择。任何时候，如果公司需要一个只有十个人使用的仪表盘，那么构建一个完整的 React 单页应用（SPA）就是一种组织成本，而不是一项功能。JavaScript 包需要维护，前端开发人员需要了解 API 接口，还需要有人管理部署流程。而使用服务器端渲染的 HTML 和 HTMLX，只需要一个应用程序，一次部署。构建数据模型的开发人员也负责构建用户界面。这并非简单，而是经济高效。
处于创意验证阶段的小型创业公司。如果你还不确定你的产品是否可行，那么在与用户交流之前就花费三个月时间构建一个完善的 React 前端，这可能是一个不明智的决定。Django + HTML 可以让 Python 开发者在几天内交付一个用户可以点击浏览的界面。这并非一劳永逸的架构，但也无需如此。
内容丰富且具有一定交互性的网站。例如，一个包含评论区、搜索栏和新闻简报订阅的博客。HTML 可以简洁地处理这些交互。你无需为了这三个交互元素而引入前端框架。
真正困难的地方在于，当你需要丰富的客户端状态时。这类应用的用户界面本身就是产品——设计工具、实时协作、复杂的数据可视化（需要具备本地筛选和排序功能），而且这些功能必须即时响应。React 及其生态系统在这方面确实更胜一筹。这并非勉强承认，而是事实。
团队协作方面也存在一个常被人们忽视的因素。很多团队的后端开发人员精通 Python，但前端技能一般，缺乏深度。React 生态系统要么需要真正的前端专业知识，要么需要愿意大量照搬 Stack Overflow 上的各种方法。HTML 的服务器端渲染则能充分发挥 Python 开发人员的优势，无需专门的 Python 开发人员。在全栈 Python 开发人员比 React 开发人员更容易找到且成本更低的市场中，这一点在组织架构上至关重要。
如果你想理解其中的理念而不仅仅是机制，那么亚当·约翰逊关于 Django + HTMX 模式的研究以及HTMX 文档中关于超媒体的文章都值得一读。这里的论点并非“单页应用（SPA）是个错误”，而是更接近于：Web 平台扩展了 HTML 以支持通过 JavaScript 实现交互，但或许它应该扩展 HTML 本身。HTMX 正是基于这种理念而诞生的。它是一个小巧而专注的库——未压缩后仅约 14kb——并且刻意限制了其功能范围。它只负责一件事，其余的都由 HTML 和 HTTP 来完成。
我一直觉得有些东西很难用语言表达，但却很重要。React 针对的是一种特定的开发者体验——开发者在组件内部，以状态、属性和效果为核心进行思考的体验。一旦你真正理解并接受这种思维模式，它就会成为一个强大的工具。但这种思维模式需要你完全投入，而且它也带来了很多复杂性。
HTML 针对的是另一种体验——服务器端完全掌控一切，浏览器只是简单地显示服务器端输出的内容。这是一种更为传统的模式，它更贴近人们实际思考数据和业务逻辑的方式，而这些数据和逻辑都运行在服务器端。对于许多开发者，尤其是那些真正擅长数据、后端系统和 API 的开发者来说，这种模式更加自然，也减少了上下文切换的次数。
两者之间没有绝对的优劣之分。它们分别适用于不同的问题、不同的团队以及产品生命周期中的不同阶段。
然而，到了2026年，我们仍然可以肯定的是，HTML已经凭借其在生产环境中的出色表现，赢得了应有的重视。这并非是对现代工具的抵制，也并非是对PHP“意大利面条式”代码的怀念。它是一种构建Web界面的切实方法，尤其适用于特定、庞大且尚未得到充分重视的应用类别——而这正是我们大多数人大部分时间都在构建的应用类型。
我最终重建了那个管理后台。用了三天时间，用了 FastAPI、Jinja2 模板和 HTML。没有构建步骤。没有像小国那么大的 node_modules 文件夹。后端团队的每个开发人员都可以阅读和修改模板，而无需学习新的编程范式。
它还在运行。没人要求我用 React 重写它。
