大家好，我卡頌。

前端領域這幾年涌現(xiàn)了很多新興的前端框架，比如Qwik?、Svelte?、Astro等。

這些框架多以「前端工程師」作為受眾。

那么，以「后端工程師」作為受眾的前端框架是啥樣的，他與前者有什么區(qū)別呢？

介紹htmx

htmx?是一款在Django技術棧最近比較熱門的前端框架。

他的理念是 —— 「讓網(wǎng)頁回歸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指定）發(fā)起post請求。

那請求返回的數(shù)據(jù)如何顯示呢？我們再增加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?觸發(fā)keyup?事件且值改變后，延遲500ms，向trigger_delay?接口發(fā)起請求，返回的HTML結構被注入到「id為search-results的DOM」中。

與其說htmx是一款前端框架，更貼切的說，他應該是一款「HTML自定義屬性工具庫」。

他將很多常見JS?交互邏輯收斂到自定義HTML?屬性中，借此減少JS代碼量。

現(xiàn)代前端框架通常是「狀態(tài)驅動UI」，而htmx?的理念是「過程驅動UI」（類似jQuery時代編寫頁面的方式）。

如果希望引入狀態(tài)，需要以插件的形式引入alpine-morph。

相比于：

• React：基于JSX。
• Vue：基于模版語法。

alpine?是一款基于HTML的前端框架。

這意味著使用alpine?需要直接在HTML?中以自定義屬性的形式書寫狀態(tài)（與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>

這段代碼包含了交互邏輯與前端狀態(tài)，最重要的是：他是合法的HTML（而不是JSX或模版語法這樣的DSL），這意味著他能輕松的在前后端之間傳遞，并在前端展示。

交互邏輯守恒

本質來說，網(wǎng)頁的最終消費品是HTML與CSS?。開發(fā)者編寫交互邏輯改變HTML與CSS。

前端工程師習慣在網(wǎng)頁中通過JS編寫交互邏輯。

后端工程師習慣在后端編寫交互邏輯。比如在htmx?中，請求返回的是HTML?結構，這部分「生成HTML的邏輯」是在后端controller?中實現(xiàn)的（而不是在前端通過JS生成）。

除此之外，還有一部分交互邏輯是在后端「HTML模版」中產生的。下圖是Django?中結合htmx的后端模版代碼示例：

不管交互邏輯在前端還是后端實現(xiàn)，也不管用哪種語言實現(xiàn)，他是一定需要實現(xiàn)的，也就是說「交互邏輯守恒」。

但是，交互邏輯在前端還是后端實現(xiàn)，對頁面帶來的影響是不同的。

對頁面性能的影響

交互邏輯在前端實現(xiàn)的越多，意味著「越多的JS代碼」，如果這部分代碼是首屏渲染所需的，那意味著更差的FCP[1]指標。

如果這部分代碼是后續(xù)交互所需的，那意味著更差的TTI[2]指標。

為了減少前端JS?資源對性能的影響，前端框架都在逐步向后迭代，比如Next.js?之于React?，Nuxt.js?之于Vue。

新興框架中的Astro?、Qwik等也是類似思路。

而本文聊的htmx?作為后端主導的前端框架，本身的立足點就是后端的view層，所以天生就是頁面性能友好的。

總結

根據(jù)「交互邏輯守恒」，交互邏輯一定需要實現(xiàn)，不是在前端就是在后端。

傳統(tǒng)來說，前端框架將交互放在前端，這會造成JS資源變大，影響性能。

單純從功能來講，htmx僅僅是個「HTML自定義屬性工具庫」，他將一部分交互收斂到自定義屬性中，減少前端交互邏輯。

剩下的交互邏輯放在后端的view?（作為頁面模版），或controller?（將HTML?作為接口返回值），以此減少前端JS資源的體積。

對于頁面交互復雜度不高，且是后端主導的項目（不想寫JS?邏輯），相信htmx會是不錯的選擇。

參考資料

[1]FCP:https://web.dev/fcp/。

[2]TTI:https://web.dev/tti/。