我一直关注着htmx。我认为它是一个有点搞笑/尴尬的梗，它为网络开发中正在进行的真正工作提供了一些轻松的喜剧效果，比如React Server Components、Svelte Runes 和Signals，这些技术实际上正在推动着技术发展。
不幸的是，在2023 年中旬，人们开始认真对待 htmx，原因有些原因。这是一个极其令人担忧的事件，让我对网络开发的未来深感担忧。
而且，我并不是唯一一个感到担忧的人：你可以在这里阅读一篇关于 htmx 的精彩批评文章
基本上，他们完全暴露了自己的无知，然后将各种无稽之谈的优点归功于他们所做的一切，希望其他人为此拍拍他们的背。
太对了。太对了。
不幸的是，这篇优秀的中篇文章的语言是学术性的，如果没有对理论 HTML 有着牢固的理解，许多重要的观点对于一般的网络开发人员来说会难以理解。
所以，在本文中，我将尝试用通俗易懂的语言向非专业网络开发人员解释htmx 为什么很糟糕.
首先，考虑 htmx 的代码。
他们在代码中到处使用 var，几乎没有使用任何现代 JavaScript 特性（你好，htmx 人，你们听说过模块吗？），他们污染了 window 命名空间，等等等等。
最糟糕的是，它只是一个巨大的 JavaScript 球！只有一个文件！它根本没有分解。如果这个人上了我在 MSU 的课程，我只会因为他完全不理解关注点分离而让他不及格，任何计算机科学的大一新生都应该能够理解这一点。
好的软件从干净的代码开始，而这段代码很脏。
下一个危险信号是缺乏构建步骤。htmx 不仅没有传统的构建步骤，从而剥夺了他们自己享受好处，其他 JavaScript 社区都在享受这些好处，而且他们还吹嘘这一点！
而且情况更糟。
如果你仔细观察，即使他们声称没有构建步骤，他们实际上确实有构建步骤，它只是一组他们自己编写的临时 bash 脚本。
荒谬且不诚实。可耻。
尽管对于像 htmx 这样的项目来说，明显的好处是使用TypeScript，但作者们一直顽固地拒绝使用它。这其中一部分原因是他们对构建步骤的非理性反对（他们实际上确实有，顺便说一下！），但另一部分原因是他们对“发布可调试源代码”的荒谬承诺。当然，任何不是完全白痴的 JavaScript 开发人员都知道，TypeScript 支持源映射，使它完全可调试。尽管有这个事实，作者们仍然坚持使用过时的 JavaScript 版本进行开发。
他们现在 belatedly 在代码库中添加了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 应用程序模型中，这个问题已经解决了。
前端/后端分离已经被证明是公司非常好的组织模式，特别是在他们扩大开发团队规模时，放弃它而采用“全栈”（所谓的）开发是冒险的，坦率地说，是愚蠢的。
撇开前端/后端分离是否好坏不谈，我们可以肯定地说，后端工程师制作的 UI 很垃圾。
看看htmx 网站。你有内联样式、表格、一堆没有 alt 描述的图像标签。只是一堆糟糕的 HTML，来自试图告诉我们使用 HTML 的人！
你应该将用户界面交给懂得如何正确构建它们的人，而这些人，今天，主要是前端 SPA 开发人员。
回到你不应该使用 htmx 的一个更技术性的原因，它会让你容易受到一类称为跨站点脚本攻击的安全性问题的攻击，简称“XSS”。
这里的问题是 htmx 设计的根本问题：它允许甚至鼓励你在标记中添加行为。我们再次看到明显违反了关注点分离。我们很早就知道，在网络开发中，你应该将标记、样式和行为分别分离到 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：创造者显然是失控的。
看看他们的推特：不专业、幼稚、故意挑衅。
或者考虑这样一个事实：他将他不同意的文章) 发布到自己的网站上。
文章标签有一个专门用于表情包的区域，大部分令人尴尬，而且这些表情包根本不应该出现在一个期待被认真对待的前端库的网站上。
显然，他允许任何人都成为 htmx 的 CEO，并在 LinkedIn 上发布那种超级尴尬的招聘公告。
无端的滑稽行为。
当你选择一个前端库时，在某种程度上，你也在选择该库的作者作为你的同事。你真的想和这个人一起工作吗？我肯定不想。
我希望这能说服你，选择 htmx 和超媒体来构建你的 Web 应用程序是一个极其糟糕的决定，它只能起源于蒙大拿州。不要听信那些“它太过了”、“我们回来了”之类的废话、CEO 简介和幼稚的表情包的粉丝和追随者。
软件，尤其是前端软件，是一项严肃的业务，需要像对待法律和政治等其他极其严肃和富有成效的活动一样认真对待。我们应该支持专注于创新和精致的库，而不是那些破碎、落伍、其创造者大部分时间都在推特上发布荒谬内容的库。
这是常识：htmx 很烂。