,周而复始。htmx的流行以前在Web上很简单。URL指向服务器，服务器将数据混合成html，然后在浏览器上呈现该响应。围绕这个简单的范式，诞生了各种Javascript框架。以前需要几个月才能完成一个应用程序的基本功能，现在在这些框架的帮助下，创建相对复杂的项目只需要几个小时。我们节省了大量的时间，这样我们就可以把更多的精力花在业务逻辑和应用程序设计上。但随着网络的不断发展，Javascript失控了。不知何故，我们决定向用户扔一大堆App，在使用的过程中不断增加网络请求；不知何故，为了生成html，我们必须使用JSON，发出几十个网络请求，丢弃我们在这些请求中得到的大部分数据，用一个越来越不透明的javascript框架黑盒将JSON转换为html，然后修补新的html到DOM中……大家是不是忘了我们可以在服务器上渲染html了？更快、更一致、更接近应用程序的实际状态，并且不向用户设备发送任何不必要的数据？但是如果没有Javascript，我们必须在每次操作时重新加载页面。现在，有一个新的库放弃了自定义方法，它就是htmx。作为未来Web开发理念的实现，其原理很简单：从任何用户事件发出AJAX请求。让服务器生成表示该请求的新应用程序状态的html。在响应中发送该html。将该元素推送到DOM中它应该去的地方。Htmx出现于2020年，创始人CarsonGross说htmx起源于他2013年研究的一个项目intercooler.js。2020年，他重写了不依赖jQuery的intercooler.js，改名为htmx。然后他对Django社区接受它的速度和戏剧性感到惊讶！图片来源：https://lp.jetbrains.com/django-developer-survey-2021-486/CarsonGross认为htmx已经成功赶上了开发者对现有Javascript框架不满的浪潮，“这些框架非常复杂并且经常将Django变成一个愚蠢的JSON生产者”，而htmx开箱即用地与Django配合得更好，因为它通过html与服务器进行交互，而Django非常擅长生成html。对于htmx的迅速流行，卡森·格罗斯感叹：这真是“这又是一个十年一夜成名的例子”。htmx的实际效果可以肯定，htmx肯定是可以用的。从理论上讲，这种方法确实值得称道。但软件问题最终归结为实际效果：效果好不好，能不能给前端开发带来提升？在DjangoCon2022上，Contexte的DavidGuillot演示了他们在一个真正的SaaS产品上从React迁移到htmx，并且效果非常好，堪称“所有htmx演示之母”（视频地址：https://www.youtube.com/观看...）。Contexte项目是2017年开始的，后台比较复杂，前端UI也很丰富，但是团队很小。所以一开始他们顺应潮流选择了React来“构建一个API绑定SPA，实现客户端状态管理，前后端状态分离”等。但是在实际应用中，由于API设计不当，DOM树太深，需要加载大量信息，导致UI“非常非常慢”。在敏捷开发的要求下，团队中唯一的Javascript专家被项目的复杂性搞得不知所措，于是决定尝试htmx。九大数据改进所以我们决定大胆尝试，花了几个月的时间，用简单的Django模板和htmx替换了SaaS产品中使用了两年的ReactUI。在此分享一些相关经验，并发布各种具体指标，希望能帮助同样关注htmx的朋友找到说服CTO的理由！这项工作总共耗时约2个月（使用21K行代码库，主要是JavaScript），而不会降低应用程序的用户体验(UX)将代码库的大小减少67%（从21500行到7200行）增加Python代码大小减少140%（从500行到1200行）；这对喜欢Python的开发人员来说应该是件好事将整体JS依赖性减少96%（从255减少到9）Web构建时间减少88%（从40秒减少到5秒）首次加载交互时间减少50%到60%（从2到6秒到1到2秒）在使用htmx集时处理更大的数据，超过React的处理限制Web应用程序的内存使用量减少了46%（从75MB到40MB）。这些数字非常令人惊讶，反映了Contexte应用程序非常适合超媒体的客观结果：这是一个以内容为中心的应用程序，用于显示大量文本和图像。显然，其他Web应用在迁移后可能没有同样夸张的提升。但是一些开发人员仍然相信大多数应用程序肯定会受益于超媒体/htmx方法，至少在某些系统上是这样。开发团队的构成可能很多朋友都没有注意到，而移植本身对团队架构有着直接的影响。当Contexte使用React时，后端和前端之间存在硬分割，两名开发人员全职管理后端，一名开发人员只管理前端，另一名负责“全栈”。（这里的“全栈”是指开发者可以轻松接管前后端的工作，因此可以在整个“栈”上独立开发功能。）移植到htmx后，整个团队变成了“全栈”“开发人员。因此，每个团队成员都更有效率，能够贡献更多价值。这也让开发变得更加有趣，因为开发人员可以自己掌握全部功能。最后，转向htmx也带来了一个新的水平软件优化，现在开发者可以在堆栈的任何地方进行优化，而无需提前与其他开发者协调htmx是对传统思维的回归在单页应用（SPA）风行的今天：JS或TS密集前端-以React、Redux或Angular等库结尾的库已成为创建Web应用程序的主流方式。以一个需要转成JS的SPA应用为例：但是htmx风潮来了，人们开始强调一种“傻瓜客户端”的方法，即服务端生成htmlbody发送给客户端，这意味着UI事件将被发送到服务器进行处理。使用此示例作为前后比较，我们看到前者涉及更多活动部件。从客户端的角度来看，后者实际上避免了自定义客户端技术，而是采用更简单的方式，将原本只作为数据引擎的服务端变成了视图引擎。后一种方法称为AJAX（异步JavaScript和XML）。这个简单的想法允许响应速度更快的Web应用程序体验，同时消除了可怕的“回发”（即网页的完全刷新），从而避开了.NET技术，例如效率极低的“viewstate”。htmx在很多方面都体现了AJAX思想的回归，最大的区别是它只作为一个新的声明性html属性出现，负责指示触发条件是什么，发布到哪个端点等。另一个被简化的元素是物理应用程序的结构和构建管道。由于不再涉及手写JS，并且整个应用程序都是基于服务器的，因此不需要（即时）JS压缩器、打包器和转译器。甚至客户端项目也被释放出来，一切都由Web服务器项目负责，所有应用程序代码都在.NET之上运行。从这个角度来看，这与高度依赖服务器的BlazorServer编程模型非常相似。关于技术和软件开发的一件有趣的事情是相同的模式来来去去并重复。随着SPA的兴起，AJAX一度被认为已死，但基本思路是卷土重来。当然会有不同的权衡，比如更高的服务器负载和网络流量（毕竟我们现在发送的是数据的视图，而不仅仅是数据），但是对于开发者来说有多种选择肯定不是坏事。虽然我不确定这种趋势是否适用于具有丰富用户体验的高复杂性应用程序，但毫无疑问，很大一部分Web应用程序不需要完整的SPA结构。对于这些类型的用例，一个简单的htmx应用程序可能是最好的解决方案。参考链接：https://news.ycombinator.com/item?id=33218439https://htmx.org/essays/a-real-world-react-to-htmx-port/https://www.reddit.com/r/django/comments/rxjlc6/htmx_gaining_popularity_rapidly/https://mekhami.github.io/2021/03/26/htmx-the-future-of-web/https://www.compositional-it.com/news-博客/更多关于htmx-回到未来/
