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