我关注htmx已经有一段时间了。我原以为这只是个有点可笑/尴尬的梗，为网页开发领域的实际工作（如React服务器组件、Svelte符文和信号等真正推动技术进步的事物）提供些轻松的喜剧调剂。
不幸的是，在2023年年中某个时候，人们开始因为某些原因认真对待htmx。这对网页开发的未来是个极其危险的信号，让我深感忧虑。
而且不止我一个人感到担忧：你可以阅读这篇对htmx的精彩批评：
基本上他们把自己的无知完全展示出来，然后为他们所做的任何事情赋予各种毫无根据的优点，希望其他人都为此拍拍他们的背。
太对了。简直不能更对。
不幸的是，那篇优秀的中帖使用的语言过于学术化，如果没有扎实的HTML理论基础，许多重要观点会让普通网页开发者难以理解。
因此，在本文中，我将尝试用通俗易懂的语言，向普通网页开发者解释为什么htmx糟透了。
首先看看htmx的代码。
他们到处使用var，几乎没有现代JavaScript特性（喂，htmx的人，你们听说过模块吗？），污染window命名空间，问题层出不穷。
最糟糕的是，它就是一个大杂烩的JavaScript！一个文件！完全没有分解。如果这个人上过我在MSU的课，单凭这种对关注点分离的完全误解，我就会让他挂科——这可是计算机科学大一学生都应该掌握的概念。
好的软件始于干净的代码，而这代码肮脏不堪。
下一个危险信号是缺乏构建步骤。htmx不仅没有传统的构建步骤，从而无法享受JavaScript社区其他成员享有的好处，他们还恬不知耻地炫耀这一点！
更糟的是。
如果你仔细观察，尽管他们声称没有构建步骤，但实际上确实有，只是他们自己写的一套临时bash脚本。
荒谬又不诚实。可耻。
尽管对于htmx这样的项目来说，TypeScript的好处显而易见，但作者们顽固地拒绝使用它。部分原因是他们非理性地反对构建步骤（顺便说一句，他们实际上有构建步骤！），部分原因是他们荒谬地坚持"发布可调试的源代码"。当然，任何不是完全白痴的JavaScript开发者都知道，TypeScript支持源映射，完全可以调试。尽管有这个事实，作者们仍坚持使用过时的JavaScript版本进行开发。
他们现在正勉强地给代码库（我在这里用词很宽松）添加JSDoc注释，这等于默认承认搞砸了。这一切都是为了弥补他们最初没有做显而易见、正确的事情：用现代、模块化的TypeScript编写整个项目。
这里唯一的好消息是，至少他们有一个还算像样的测试套件，考虑到代码库的状态，他们最好有！
好了，以上涵盖了htmx代码库本身的主要（但远非全部！）问题。让我们继续讨论htmx更普遍的问题。
第一个 glaring issue（作者们居然还引以为豪）是：它使用超媒体。这其实就是"使用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">
加载
</button>
哇。真了不起。
如果不是这么令人愤怒的话，可能会很搞笑。
不使用htmx的另一个原因是它没有任何可用的组件。如果你选择React，你可以获得MUI、NextUI和Chakra等组件。
使用htmx，你得到的是...什么都没有。你必须自己决定要使用哪些组件，然后弄清楚如何通过事件等方式将它们与htmx集成。
你真的想花时间弄清楚像lit这样的东西如何工作，然后还要弄清楚如何将它们与htmx集成吗？这毫无意义。不如选择一个有现成集成组件的前端库，可以直接使用而无需任何麻烦。
避免使用htmx的另一个主要原因是它消除了后端和前端团队的分离。他们甚至有一个页面将其作为优点炫耀，当他们的公司（愚蠢地）从React转向htmx时。
前后端分离对许多公司来说非常成功，它让前端工程师专注于构建良好的用户体验，而后端工程师专注于正确处理数据访问层。
是的，有时两个团队之间的协调会有一些困难，后端工程师抱怨前端工程师频繁变更需求，而前端工程师抱怨后端工程师动作太慢。但我们现在有GraphQL和RSC等技术来解决这些问题，这在现有的标准网页应用模型中已经是个已解决的问题。
前后端分离已被证明是公司非常好的组织模式，特别是在扩展开发团队时，放弃它转而采用"全栈"（所谓的）开发是冒险的，坦率地说，是愚蠢的。
暂且不论前后端分离是好是坏，我们可以明确地说，后端工程师做出的用户界面很糟糕。
看看htmx的网站就知道了。到处都是内联样式、表格，一堆图片标签长期没有alt描述。简直就是糟糕HTML的大杂烩，来自一群试图告诉我们使用HTML的人！
你应该把用户界面交给懂得如何正确构建它们的人，而这些人今天大多是前端SPA开发者。
回到另一个不应该使用htmx的技术原因，它会让你面临一类称为跨站脚本攻击（简称"XSS"）的安全问题。
这里的问题在于htmx设计的根本：它允许甚至鼓励你在标记中放置行为。我们再次看到了对关注点分离的明显违反。多年来我们都知道，在网页开发中应该将标记、样式和行为分别放在HTML、CSS和JavaScript文件中。
通过违反这个显而易见且众所周知的真理，htmx让你容易受到他人向你的网页应用中注入行为的攻击，如果你没有正确清理HTML的话。
有时候htmx的作者会自作聪明地说："那么你对href属性怎么看？"，但这显然不同。
不使用htmx的另一个现实原因是，粗略地说，htmx的工作机会为零。
我刚在indeed上搜索htmx工作，总共只找到两个：一个在微软，一个在橡树岭国家实验室。
而搜索"react"，则得到13,758个工作。
说真的，开发者，你想把自己的职业生涯押注在这两种技术中的哪一种上？
上述问题的另一面是，如果你是一家公司，粗略地说，htmx开发者为零。
每个人都去培训班学习React。如果你想有大量潜在的员工池（也许你的公司因为某些原因人员流动率高，也许你想压低员工工资，也许一小队全栈工程师会妨碍你建立王国），选择前端开发的大佬要有意义得多。
今天，这个大佬是React。
回到技术层面，如果你采用htmx，并且还想要一个移动应用或供第三方使用的API，你将需要完全独立于网页应用的端点创建那个API。
在这里，我们再次发现，令人难以置信的是，htmx的人居然以此为荣，完全忽视了这里涉及的工作重复。
更合理的做法是让一个后端团队维护一个单一的API，可以灵活地满足你所有的需求。
这是显而易见的，坦率地说，甚至不值得争论。
htmx的另一个技术问题是它无法扩展。它可能适用于小型应用，但随着应用规模扩大，htmx模型会崩溃并变得一团糟。React和其他前端工具的组件模型将所有东西都分隔开并保持可测试性。这使得保持大型代码库的整洁要容易得多。
举个例子，考虑GitHub，它最初使用的技术与htmx非常相似。最近它开始采用React，现在比以前稳定得多。如果他们一开始就用React以现代、基于组件的方式构建整个东西会更好，但至少现在他们做出了正确的选择。迟到总比不到好。
最后，也许是不使用htmx最重要的原因：创建者显然精神不正常。
看看他的推特动态：不专业、幼稚、故意挑衅。
文章标签有一个梗图专区，大多数都让人尴尬，所有这些都不应该出现在一个期望被认真对待的前端库网站上。
显然他允许任何人成为htmx的CEO，并在LinkedIn上发布那些超级尴尬的职位公告。
肆无忌惮的胡闹。
当你选择一个前端库时，在某种程度上，你是在选择该库的作者作为同事。你真的想和这家伙一起工作吗？反正我不想。
我希望这能说服你，选择htmx和超媒体作为你的网页应用是个极其糟糕的主意，这种想法只能源自蒙大拿州。不要听那些粉丝们"一切都结束了"、"我们又回来了"的废话、CEO简介和幼稚的梗图。
软件，尤其是前端软件，是严肃的事业，需要像对待法律和政治（另外两个极其严肃和富有成效的活动）一样认真对待。我们应该支持专注于创新和复杂性的库，而不是那些破碎、向后看的库，其创建者大部分时间都在推特上发布荒谬的内容。
这是常识：htmx糟透了。