htmx：后端主导的前端框架是什么？

时间：2023-03-13 22:03:33 科技观察

大家好，我是Kason。近年来，前端领域涌现了很多新兴的前端框架，比如Qwik、Svelte、Astro等，这些框架大多面向“前端工程师”。那么，以“后端工程师”为受众的前端框架到底是什么，他和前者有什么区别呢？简介htmxhtmx是最近Django技术栈中比较流行的前端框架。他的理念是——“让网页回归HTML本质，不再受JS束缚”。是不是很web1.0风格？他是怎么做到的呢？答案是：通过大量预制的自定义HTML属性。将htmx.org.js导入页面后，您可以在HTML中编写以hx-开头的自定义属性。例如下面的代码：点我请求数据点击按钮（hx-trigger指定的点击事件）后，数据接口（hx-post规范）发起post请求。如何显示请求返回的数据？让我们再添加2个自定义属性：Clickmetorequestdatahx-target指的是“返回的HTML结构”将被注入的位置。这将被注入到“id为parent-div的DOM”中。hx-swap指的是“返回的HTML结构将以何种形式注入”。这将直接替换“id为parent-div的DOM”。如果hx-swap="innerHTML"，则表示将以“id为parent-div的DOM”的innerHTML形式注入。如果要表达复杂的逻辑，需要组合很多自定义属性和属性值，比如下面的代码：当输入触发keyup事件，值发生变化时，延迟500ms发送到trigger_delay接口，返回的HTML结构为注入“id是DOM中的搜索结果”。与其说htmx是一个前端框架，不如说它应该是一个“HTML自定义属性工具库”更合适。他将很多常见的JS交互逻辑汇聚到自定义的HTML属性中，从而减少JS代码量。现代前端框架通常是“状态驱动的UI”，而htmx的概念是“进程驱动的UI”（类似于jQuery时代的页面编写方式）。如果要引入state，需要以插件的形式引入alpine-morph。对比：React：基于JSX。Vue：基于模板语法。alpine是一个基于HTML的前端框架。这意味着使用alpine需要直接在HTML中编写状态作为自定义属性（类似于Vuev1）。因此，他可以很好的融入到htmx系统中。例如，下面一段代码是一段结合了htmx和alpine的HTML，其中htmx属性以hx-开头，alphine属性以x-开头：

Morph

这段代码包含交互逻辑和前端状态，最重要的是：它是合法的HTML（而不是像JSX或模板语法那样的DSL），这意味着它可以很容易地在前端和前端之间传递，并显示在前端。交互逻辑守恒本质上，网页的最终消费品是HTML和CSS。开发人员编写交互逻辑来更改HTML和CSS。前端工程师习惯于通过JS编写网页中的交互逻辑。后端工程师习惯于在后端编写交互逻辑。例如在htmx中，请求返回一个HTML结构，而这部分“生成HTML的逻辑”是在后端controller中实现的（而不是前端由JS生成）。另外，部分交互逻辑是在后台“HTML模板”中生成的。下图是Django中结合htmx的后端模板代码示例：不管交互逻辑是在前端还是后端实现，也不管用哪种语言实现，必须实现，即“交互逻辑守恒”。但是无论交互逻辑是在前端还是后端实现，对页面的影响是不同的。对页面性能的影响前端实现的交互逻辑越多，就意味着“JS代码越多”。如果首屏渲染需要这部分代码，就意味着FCP[1]指标变差了。如果后续交互需要这部分代码，则意味着更糟糕的TTI[2]指标。为了减少前端JS资源对性能的影响，前端框架逐渐向后迭代，比如React的Next.js，Vue的Nuxt.js。新兴框架中的Astro、Qwik等也有类似的想法。作为后端主导的前端框架，本文所讨论的htmx是基于后端的视图层的，所以天生就是页面友好的。总结根据“交互逻辑守恒”，交互逻辑必须实现，要么在前端，要么在后端。传统上，前端框架将交互放在前端，会导致JS资源变大，影响性能。从纯功能的角度来看，htmx只是一个“HTML自定义属性工具库”，将部分交互汇聚成自定义属性，减少前端交互逻辑。其余的交互逻辑放在后端view（作为页面模板），或者controller（使用HTML作为接口返回值），减少前端JS资源量。对于页面交互复杂度不高，后端主导的项目（不想写JS逻辑），相信htmx会是一个不错的选择。参考文献[1]FCP：https://web.dev/fcp/。[2]TTI：https://web.dev/tti/。