大家好，我卡頌。

創(chuàng)新互聯(lián)公司是一家專業(yè)提供彌渡企業(yè)網(wǎng)站建設,專注與網(wǎng)站制作、網(wǎng)站設計、HTML5建站、小程序制作等業(yè)務。10年已為彌渡眾多企業(yè)、政府機構(gòu)等服務。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設計公司優(yōu)惠進行中。

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

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

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

介紹htmx

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

他的理念是 —— 「讓網(wǎng)頁回歸HTML的本質(zhì)，不再受JS束縛」。是不是很有web1.0的風格？

他是怎么做到的呢？答案是：通過大量預制的自定義HTML屬性。

當你在頁面中引入htmx.org.js?后，可以在HTML?中書寫以hx-開頭的自定義屬性。比如下面的代碼：

  hx-post="/data"
  hx-trigger="click"
>
  點我請求data

點擊按鈕（hx-trigger指定的click事件）后，會向data接口（hx-post指定）發(fā)起post請求。

那請求返回的數(shù)據(jù)如何顯示呢？我們再增加2個自定義屬性：

  hx-post="/data"
  hx-trigger="click"
  hx-target="#parent-div"
  hx-swap="outerHTML"
>
    點我請求data

hx-target指代「返回的HTML結(jié)構(gòu)」會被注入到哪里。這里會被注入到「id為parent-div的DOM」中。

hx-swap指代「返回的HTML結(jié)構(gòu)會以什么形式注入」。這里會直接替換「id為parent-div的DOM」。

如果hx-swap="innerHTML"?，則代表會以「id為parent-div的DOM」的innerHTML形式注入。

如果要表達復雜的邏輯，需要結(jié)合很多自定義屬性與屬性值，比如下面的代碼：

  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結(jié)構(gòu)被注入到「id為search-results的DOM」中。

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

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

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

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

相比于：

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

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

這意味著使用alpine?需要直接在HTML?中以自定義屬性的形式書寫狀態(tài)（與Vue v1?類似）。所以，他能很好的融入htmx的體系中。

比如下面這段代碼是段結(jié)合htmx與alpine的HTML?，其中以hx-?開頭的是htmx?屬性，以x-?開頭的是alphine屬性：

  

      
      

                    x-on:click="replaced = true; count++" 
              hx-get="/swap">
        Morph
      
  

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

交互邏輯守恒

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

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

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

除此之外，還有一部分交互邏輯是在后端「HTML模版」中產(chǎn)生的。下圖是Django?中結(jié)合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層，所以天生就是頁面性能友好的。

總結(jié)

根據(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/。

本文題目：Htmx：后端主導的前端框架是啥樣的？
網(wǎng)頁鏈接：http://uogjgqi.cn/article/djogihi.html