大家好，我卡颂。

前端畛域这几年涌现了很多新兴的前端框架，比方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会是不错的抉择。