共计 2417 个字符，预计需要花费 7 分钟才能阅读完成。
大家好，我卡颂。
前端畛域这几年涌现了很多新兴的前端框架，比方 Qwik、Svelte、Astro 等。
这些框架多以 前端工程师 作为受众。
那么，以 后端工程师 作为受众的前端框架是啥样的，他与前者有什么区别呢？
欢送退出人类高质量前端框架群，带飞
介绍 htmx
htmx是一款在 Django 技术栈最近比拟热门的前端框架。
他的理念是 —— 让网页回归 HTML 的实质，不再受 JS 解放 。是不是很有web1.0 的格调？
他是怎么做到的呢？答案是：通过大量预制的自定义 HTML 属性。
当你在页面中引入 htmx.org.js 后，能够在 HTML 中书写以 hx- 结尾的自定义属性。比方上面的代码：
<button
hx-post="/data"
hx-trigger="click"
>
点我申请 data
</button>点击按钮（hx-trigger指定的 click 事件）后，会向 data 接口（hx-post指定）发动 post 申请。
那申请返回的数据如何显示呢？咱们再减少 2 个自定义属性：
<button
hx-post="/data"
hx-trigger="click"
hx-target="#parent-div"
hx-swap="outerHTML"
>
点我申请 data
</button>hx-target指代 返回的 HTML 构造 会被注入到哪里。这里会被注入到 id 为 parent-div 的 DOM 中。
hx-swap指代 返回的 HTML 构造会以什么模式注入。这里会间接替换id 为 parent-div 的 DOM。
如果 hx-swap="innerHTML"，则代表会以id 为 parent-div 的 DOM 的innerHTML模式注入。
如果要表白简单的逻辑，须要联合很多自定义属性与属性值，比方上面的代码：
<input
type="text"
hx-get="/trigger_delay"
hx-trigger="keyup changed delay:500ms"
hx-target="#search-results"
placeholder="Search..."
>当 input 触发 keyup 事件且值扭转后，提早 500ms，向 trigger_delay 接口发动申请，返回的 HTML 构造被注入到 id 为 search-results 的 DOM 中。
与其说 htmx 是一款前端框架，更贴切的说，他应该是一款HTML 自定义属性工具库。
他将很多常见 JS 交互逻辑收敛到自定义 HTML 属性中，借此缩小 JS 代码量。
古代前端框架通常是 状态驱动 UI，而 htmx 的理念是 过程驱动 UI（相似 jQuery 时代编写页面的形式）。
如果心愿引入状态，须要以插件的模式引入alpine-morph。
相比于：
- React：基于
JSX - Vue：基于模版语法
alpine是一款基于 HTML 的前端框架。
这意味着应用 alpine 须要间接在 HTML 中以自定义属性的模式书写状态（与 Vue v1 相似）。所以，他能很好的融入 htmx 的体系中。
比方上面这段代码是段联合 htmx 与alpine的 HTML，其中以hx- 结尾的是 htmx 属性，以 x- 结尾的是 alphine 属性：
<div hx-target="this" hx-ext="alpine-morph" hx-swap="morph">
<div x-data="{ count: 0, replaced: false,
message: 'Change me, then press the button!' }">
<input type="text" x-model="message">
<div x-text="count"></div>
<button x-bind:style="replaced && {'backgroundColor':'#fecaca'}"
x-on:click="replaced = true; count++"
hx-get="/swap">
Morph
</button>
</div>
</div>这段代码蕴含了交互逻辑与前端状态，最重要的是：他是非法的 HTML（而不是JSX 或模版语法这样的DSL），这意味着他能轻松的在前后端之间传递，并在前端展现。
交互逻辑守恒
实质来说，网页的最终消费品是 HTML 与CSS。开发者编写交互逻辑扭转 HTML 与CSS。
前端工程师习惯在网页中通过 JS 编写交互逻辑。
后端工程师习惯在后端编写交互逻辑。比方在 htmx 中，申请返回的是 HTML 构造，这部分 生成 HTML 的逻辑 是在后端 controller 中实现的（而不是在前端通过 JS 生成）。
除此之外，还有一部分交互逻辑是在后端 HTML 模版 中产生的。下图是 Django 中联合 htmx 的后端模版代码示例：
不论交互逻辑在前端还是后端实现，也不论用哪种语言实现，他是肯定须要实现的，也就是说 交互逻辑守恒。
然而，交互逻辑在前端还是后端实现，对页面带来的影响是不同的。
对页面性能的影响
交互逻辑在前端实现的越多，意味着 越多的 JS 代码，如果这部分代码是首屏渲染所需的，那意味着更差的 FCP 指标。
如果这部分代码是后续交互所需的，那意味着更差的 TTI 指标。
为了缩小前端 JS 资源对性能的影响，前端框架都在逐渐向后迭代，比方 Next.js 之于 React，Nuxt.js 之于Vue。
新兴框架中的 Astro、Qwik 等也是相似思路。
而本文聊的 htmx 作为后端主导的前端框架，自身的立足点就是后端的 view 层，所以天生就是页面性能敌对的。
总结
依据 交互逻辑守恒，交互逻辑肯定须要实现，不是在前端就是在后端。
传统来说，前端框架将交互放在前端，这会造成 JS 资源变大，影响性能。
单纯从性能来讲，htmx仅仅是个HTML 自定义属性工具库，他将一部分交互收敛到自定义属性中，缩小前端交互逻辑。
剩下的交互逻辑放在后端的 view（作为页面模版），或controller（将HTML 作为接口返回值），以此缩小前端 JS 资源的体积。
对于页面交互复杂度不高，且是后端主导的我的项目（不想写 JS 逻辑），置信 htmx 会是不错的抉择。