Htmx，它到底是框架还是库？ _Htmx

文章插图
在最近的前端开发技术的探讨中，htmx经常成为热议的话题。一些人批评它，认为尽管htmx批评现代前端框架过于复杂，但它自己却似乎也是一个复杂的框架。这种看法值得我们深入思考。因为当你将任何第三方代码引入你的项目时，无论是htmx还是其他，都意味着你需要理解并维护它，尤其是在升级的时候。所以，让我们仔细分析一下这种批评，并探究htmx在解决它所宣称的问题时的实际表现。
库与框架：有何不同？关于htmx是库还是框架的讨论，常常出现在争论之中。有人辩称htmx实际上是一个库，而不是框架。但这种说法可能不太准确。
“框架”这个词在技术上并没有一个严格的定义，它和“库”之间的界限并不是那么明显。但我们还是可以尝试去区分它们：

库（Library）：这是一种API对应用程序其他部分影响不大的第三方代码。
框架（Framework）：这种代码的API则决定了应用程序的整体结构。

这个比喻可能会更加形象：库就像是你添加到机器中的齿轮，而框架则像是一个你通过定制齿轮来控制的预制机器。
这种区别之所以重要，是因为它关系到代码的可替换性。比如，一个使用了CSV解析库的JAVAScript服务可以相对容易地更换另一个CSV解析库；但如果是使用了NextJS这样的框架，服务可能就会在整个生命周期中依赖于NextJS ，因为大量代码都是基于与NextJS构件的交互编写的。
因此，如果你的服务是基于某个框架构建的，它的有效寿命就与该框架的有效寿命紧密相连。如果那个框架被废弃、不受欢迎或难以维护，那么修改你的项目就会变得越来越困难，直到最后你不得不放弃对它的修改，并可能整个项目被搁置。
这正是人们在问“htmx只是另一个JavaScript框架吗？”时的担忧所在。他们不希望自己投入到一个很快就会过时的系统中，就像过去很多Web开发框架那样。
htmx：框架还是更多？尽管社区对此存在争议，但从我个人的角度看， htmx在大多数使用场景中显然更接近于一个框架。当然，这也取决于你如何使用它。
当你在项目中使用htmx时，你会在html中包含htmx的属性（比如hx-post ， hx-target），编写以htmx格式化数据（带有特定请求头）来调用的端点，并从这些端点返回htmx期望的格式化数据（带有hx-*控制的HTML）。所有这些属性、头部和端点的相互作用，创建了一个通过网络请求使元素进入和退出DOM的系统。
如果你在网站的许多网络请求中使用htmx，那么引入htmx对项目结构的影响是显著的，从如何构建前端标记到端点进行的数据库查询，htmx的加入都会对整个应用程序架构产生深远影响。这种影响是框架式的，意味着一旦采用了htmx ，就不容易被替换掉。
当然，你也可以选择以更类似于库的方式使用htmx，仅在网页的某些部分添加动态功能。这就像你可以用类似库的方式使用React，但这并不意味着React不是一个框架。实际上，很多开发者在他们的应用中使用htmx，都是在遵循htmx的框架式要求，将其作为构建超媒体应用的一个框架。
使用htmx最有效的方式是顺应它的优势。例如，你当然可以选择发送JSON格式化的表单体，但更简单的做法是使用
Application/x-www-form-urlencoded格式，并编写一个能接受这种格式的端点。同样地，你也可以编写一个跨多个不同客户端重用的端点，但更简单的做法是将你的数据和超媒体API分离到不同的URL 。是的，htmx可以作为库使用，但让它成为你的框架可能会更好。
htmx的独特优势：HTML尽管htmx在很多情况下被当作一个框架使用，但这并不意味着它就是“另一个JavaScript框架” 。htmx最大的优势在于它的核心是HTML 。
如果你将htmx当作框架来使用，那么从一个角度来看，它确实是基于大约4000行JS实现的。但从另一个更重要的角度来看，htmx并不是：不像React、Svelte、Solid等让你编写JS(X)并将其转换为HTML的框架，htmx让你直接编写HTML 。这种方式避免了很多其他框架随着时间推移可能带来的维护问题。
例如，当你想升级或更改某些依赖时，如果你使用的框架与这种更改不兼容，代码库往往会遇到困难。Java是一个著名的例子——有无数行Java代码因为升级Spring太难而永远停留在Java 8 。但当你使用htmx时，你不会遇到这个问题，因为htmx是一个零依赖的、客户端加载的JavaScript文件，它不会与你的服务器依赖的任何构建过程或依赖链发生冲突。