我已经关注 htmx 有一段时间了。我原本认为它是一个有点搞笑/尴尬的 meme，并且它为 Web 开发中的真正工作提供了一些轻松的喜剧解压，比如 React Server Components、Svelte Runes 和 Signals，这些才是真正推动技术前沿的东西。
不幸的是，在 2023 年中旬左右 有人开始认真对待 htmx 出于 某些 原因。 这是一个极其令人震惊的转变，让我对 Web 开发的未来深感担忧。
而且我不是唯一一个感到震惊的人：你可以在这里阅读一篇优秀的 对 htmx 的严厉批评：
基本上，他们把自己的无知完全暴露出来，然后把各种毫无根据的优点归功于他们所做的事情，希望其他人能为此拍他们的马屁。
太对了。太对了。
不幸的是，那篇优秀的 Medium 文章的语言过于学术化，如果没有扎实的理论 HTML 知识，许多重要的观点会让典型的 Web 开发者听不懂。
所以，在这篇文章中，我将尝试用通俗的语言向普通 Web 开发者解释，为什么 htmx 很烂。
首先，考虑一下 htmx 的代码。
他们到处使用 var，几乎没有现代 JavaScript 特性（喂，htmx 团队，你们听说过
模块 吗？），他们污染了 window 命名空间，诸如此类，一大堆问题。
最糟糕的是，它就是一个巨大的 JavaScript 球！一个文件！完全没有分解。如果这个人 上过我在 MSU 的课，我就会因为他对 关注点分离 的完全误解而让他不及格，这可是计算机科学新生应该掌握的基本知识。
好的软件从干净的代码开始，而这段代码肮脏不堪。
下一个危险信号是缺少构建步骤。htmx 不仅没有传统的构建步骤，从而剥夺了 JavaScript 社区其他成员享有的 好处，而且他们还 积极吹嘘这一点！
情况变得更糟了。
如果你仔细看，虽然他们声称没有构建步骤，但他们 实际上有 一个构建步骤，只不过是一些他们自己写的临时 bash 脚本。
荒谬 而且 不诚实。可耻。
尽管 TypeScript 对像 htmx 这样的项目有 明显的优势，作者们却顽固地拒绝使用它。 部分原因是他们对构建步骤的非理性反对（顺便说一句，他们实际上有！），但部分原因是他们对“发布可调试的源代码”的荒谬承诺。当然，任何不是完全白痴的 JavaScript 开发者都知道， TypeScript 支持 源映射，让它完全可调试。尽管如此，作者们继续坚持使用过时的 JavaScript 版本进行开发。
在他们承认搞砸了的默许中，他们现在才迟来地为代码库添加 JSDoc 注解 （这里我宽松地使用“代码库”这个词）。这一切都是为了弥补他们最初没有做明显、正确的事情——简单地用现代、模块化的 TypeScript 编写整个项目。
这里唯一的好消息是，至少他们有一个还算不错的 测试套件，鉴于代码库的状态，他们 最好他妈的有！
好了，这涵盖了 htmx 代码库本身的主要问题（但绝非全部！）。让我们继续讨论 htmx 的更一般性问题。
第一个显而易见的问题是作者们再次吹嘘的东西：它使用 超媒体。其实这只是“它使用 HTML”的自命不凡说法，我不知道他们为什么坚持用一个不同且令人困惑的术语，但随便吧。
好了，如果你还没注意到，HTML 现在已经超过三十年了。它很古老。而且，我们对这些家伙推荐的方法有很多经验。htmx 并没有做什么新东西：intercooler.js、 PJax 和 Unpoly（顺便说一句，比 htmx 好多了）已经存在了 永远。
甚至在那之前，我们就有 jquery.load()。
看看 2008 年的这段 jQuery 代码：
$( "#result" ).load( "ajax/test.html" );
现在看看 htmx 团队给我们带来的超级创新的东西：
<button hx-get="/ajax/test.html"
hx-target="#result">
Load
</button>
哇。太棒了。
如果不是这么气人，这会很搞笑。
不使用 htmx 的下一个原因是它没有任何可用的组件。如果你选择 React，你会得到像 MUI、NextUI 和 Chakra 这样的东西。
用 htmx，你得到……什么都没有。你必须自己弄清楚要用什么组件，然后如何使用事件等方式将它们与 htmx 集成。
你真的想花时间弄清楚像 lit 这样的东西如何工作，然后 还 要弄清楚如何 将它们与 htmx 集成吗？那没有意义。远比这更好的选择是使用一个带有集成、开箱即用组件的前端库，而不用费心。
避免使用 htmx 的另一个主要原因是它消除了后端与前端团队之间的分离。他们甚至 有一个页面，团队 吹嘘这一点作为优点，当时他们的公司（愚蠢地） 从 React 转向 htmx。
前后端分离在许多公司中取得了极大成功，让前端工程师专注于构建良好的用户体验，后端工程师专注于正确处理数据访问层。
是的，有时两个团队之间协调会有一些困难，后端工程师抱怨前端工程师需求变化太频繁，前端工程师抱怨后端工程师动作太慢。但我们有像 GraphQL 和 RSC 这样的技术 来帮助解决这个问题，在现有的 标准 Web 应用模型 中，这已经是解决的问题了。
前后端分离已被证明是公司的一种非常好的组织模式，特别是当他们扩展开发团队时，放弃它转向所谓的“全栈”开发是冒险的，而且坦白说，是愚蠢的。
撇开前后端分离好坏不谈，我们可以明确地说，后端工程师制作的用户界面是垃圾。
看看 htmx 网站。你会看到内联样式、表格、一堆图像标签
长期没有 alt 描述。只是一堆糟糕的 HTML，由那些试图告诉我们使用 HTML 的人做出来的！
你应该把用户界面交给那些真正懂得如何正确构建它们的人，而这些人如今主要是前端 SPA 开发者。
回到为什么不使用 htmx 的更技术性原因，它会让你暴露在一类称为 跨站脚本攻击 的安全问题中，简称“XSS”。
这里的问题是 htmx 设计的核心：它启用并甚至鼓励你在标记中放置 行为。再次，我们看到对 关注点分离 的明显违反。我们在 Web 开发中早就知道，你应该将标记、样式和行为分别分离到 HTML、CSS 和 JavaScript 文件中。
通过违反这个明显且众所周知的真理，htmx 让你容易受到其他人注入行为到你的 Web 应用的风险，如果你没有 正确清理你的 HTML 的话。
有时 htmx 作者会聪明地说类似“那么，你对 href 属性怎么看？”，但那显然不同。
不使用 htmx 的另一个实际原因是，大约来说，没有 htmx 工作。
我刚刚在 Indeed 上搜索了 htmx 工作，只找到总共两个：一个在微软，一个在 橡树岭国家实验室。
另一方面，搜索“react”会得到 13,758 个工作。
说真的，开发者，你想把职业绑定到这两个技术中的哪一个？
上述问题的反面是，如果你是一家公司，大约来说，没有 htmx 开发者。
每个人都去培训营学习 React。如果你想有一个庞大的潜在员工池（也许你的公司 有某种原因的高流动率，也许你想压低员工工资，也许一小队全栈工程师 会妨碍你的王国建设），那么选择前端开发中的大佬更有意义。
如今，那条大狗是 React。
回到更技术性的一面，如果你采用 htmx，并且你还想 也 有一个移动应用或供第三方使用的 API，你将需要完全独立于你的 Web 应用端点来创建那个 API。
在这里，我们再次发现，令人难以置信的是，htmx 团队为此吹嘘，完全 忽略了这里涉及的工作重复。
拥有一个由单一后端团队维护的单一 API 来灵活满足所有需求更有意义。
这很明显，而且坦白说，不值得争论。
htmx 的另一个技术问题是它根本无法扩展。它可能适用于小型应用，但随着应用 变大，htmx 模型就会崩溃并变得一团糟。React 和其他前端工具的组件模型让一切都保持隔离和可测试。这让维护大型代码库变得容易得多。
作为一个例子，考虑 GitHub，它最初使用类似于 htmx 的技术。最近 它开始采用 React，现在比以前稳定得多。如果他们一开始就用 React 以现代、基于组件的方式构建整个东西会更好，但至少他们 现在做出了正确的举动。迟到总比不到好。
最后，也许是不使用 htmx 的最重要的原因：创建者显然精神失常。
看看 Twitter feed：不专业、幼稚、故意挑衅。
或者考虑这样一个事实：他把 他不同意的文章) 发到 自己的网站上。
文章标签 有一个 meme 部分，其中大多数尴尬，所有这些 都没有资格出现在一个期望被认真对待的前端库网站上。
显然，他允许 任何人成为 htmx 的 CEO 并在 LinkedIn 上发布那些超级尴尬 的工作公告。
肆无忌惮的小丑行为。
当你选择一个前端库时，在某种程度上，你就是在选择该库的作者作为同事。你 真的想和这个人共事吗？我当然不想。
我希望这能说服你，选择 htmx 和超媒体作为你的 Web 应用是一个 极其糟糕的主意，它只能 起源于 蒙大拿。不要听那些粉丝男孩和女孩的“一切都结束了”、 “我们回来了”废话、CEO 简介和幼稚 meme。
软件，尤其是前端软件，是严肃的生意，需要像法律和政治一样严肃对待，后两者也是极其严肃和富有成效的活动。我们应该支持专注于 创新和复杂性的库，而不是那些破败的、向后看的库，它们的创建者大部分时间都在 Twitter 上发布荒谬的东西。
这只是常识：htmx 很烂。