存眷
“脚本之家
”，与百万开发者在一路
出处：魔术师卡颂（ID：gh_52d0bec584f9）
如若转载请联络原公家号
前端范畴那几年涌现了良多新兴的前端框架，好比 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：基于模版语法
React：基于 JSX
Vue：基于模版语法
alpine 是一款基于 HTML 的前端框架。
那意味着利用 alpine 需要间接在 HTML 中以自定义属性的形式书写形态（与 Vue v1 类似）。所以，他能很好的融入 htmx 的系统中。
好比下面那段代码是段连系 htmx 与 alpine 的 HTML ，此中以 hx- 开头的是 htmx 属性，以 x- 开头的是 alphine 属性：
divhx-target= "this"hx-ext= "alpine-morph"hx-swap= "morph"
divx-data= "{ count: 0, replaced: false,
message: 'Change me, then press the button!' }"
inputtype= "text"x-model= "message"
divx-text= "count" / div
buttonx-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[1] 目标。
若是那部门代码是后续交互所需的，那意味着更差的 TTI[2] 目标。
为了削减前端 JS 资本对性能的影响，前端框架都在逐渐向后迭代，好比 Next.js 之于 React ， Nuxt.js 之于 Vue 。
新兴框架中的 Astro 、 Qwik 等也是类似构想。
而本文聊的 htmx 做为后端主导的前端框架，自己的安身点就是后端的 view 层，所以生成就是页面性能友好的。
总结
根据 「交互逻辑守恒」，交互逻辑必然需要实现，不是在前端就是在后端。
传统来说，前端框架将交互放在前端，那会形成 JS 资本变大，影响性能。
单纯从功用来讲， htmx 仅仅是个 「HTML自定义属性东西库」，他将一部门交互收敛到自定义属性中，削减前端交互逻辑。
剩下的交互逻辑放在后端的 view （做为页面模版），或 controller （将 HTML 做为接口返回值），以此削减前端 JS 资本的体积。
关于页面交互复杂度不高，且是后端主导的项目（不想写 JS 逻辑），相信 htmx 会是不错的选择。
参考材料
[1]
FCP: /
[2]
TTI: /
END
法式员专属卫衣
商品曲购链接
【☝🏼点击查看更多详情】
专属定造，法式员秒懂的极客卫衣！
微前端若何做款式隔离？
前端框架：性能与灵敏性的取舍
一个被忽略的前端细分范畴
一个新视角：前端框架们都卷错标的目的了？
Office 2019/2021专业加强版，正版末身受权！