近幾年的網頁開發生態裡，HTMX 這類強調後端渲染的框架悄悄累積了不少關注度。它某種程度上是對「前後端分離才是正道」的反動，值得拆開來看看背後的邏輯。

前後端分離帶來的代價

前後端分離確實有其優勢：前端專注使用者體驗、後端專注商業邏輯、API 可以服務多種客戶端、水平擴展也比較直觀。

但實際做下來，代價也不小：

  • 要同時維護兩個獨立的程式碼庫
  • 狀態管理的複雜度往往遠超業務本身的複雜度
  • 新人進入門檻明顯拉高
  • 建置與部署流程多了好幾層
  • 效能調校要在前後端各自處理一遍

對許多規模不大的專案來說，這些成本其實不太划算。

HTMX 的做法

HTMX 的核心概念很直接：把原本要用 JavaScript 才能做的互動，直接寫成 HTML 屬性。

引入方式

最快的方式是走 CDN，加一行進 <head> 就行：

1
<script src="https://unpkg.com/htmx.org@2.0.3"></script>

正式環境建議改用 npm 安裝或自行托管，避免依賴第三方 CDN；若仍走 CDN，可從 htmx.org 官方文件 取得帶 integrity hash 的完整標籤。

也可以用 npm 安裝：

1
npm install htmx.org

基本語法

1
2
3
4
5
<button hx-post="/submit" 
        hx-target="#result"
        hx-swap="outerHTML">
  送出
</button>

這三個屬性做的事：hx-post 指定送出 POST 請求的 URL，hx-target 指定要更新哪個 DOM 元素，hx-swap 指定怎麼替換（outerHTML 代表整個目標元素都被替換掉）。

關鍵在伺服器端：HTMX 期望伺服器回傳的是 HTML fragment，不是 JSON。後端直接吐一段 HTML，HTMX 把它插進指定位置，整個流程不需要任何 JavaScript。

以 Python/Flask 為例：

1
2
3
@app.route("/submit", methods=["POST"])
def submit():
    return "<div id='result'>送出成功！</div>"

主要優勢

開發效率：省去前端狀態同步的那層工作。在簡單的 CRUD 情境下，不需要在 API response 和前端狀態之間來回對應。

前端資源：HTMX 本身壓縮後約 14KB，沒有額外的 runtime。對比 React 加上狀態管理套件，差距相當明顯。

學習曲線：懂 HTML 的開發者基本上看幾個範例就能上手，不需要先學 JSX、hooks 或 reactive 的概念。

為什麼現在開始受到重視？

幾個背景因素加在一起：

複雜度的反彈：不少開發者做過幾個 SPA 後意識到，並不是每個專案都需要那個複雜度。一個內部管理系統、一個 blog、一個資料檢索介面，根本用不到完整的前端框架。

效能壓力：Core Web Vitals 變成 Google 排名因素之後，初始載入速度被正式量化。後端渲染天生就在這一塊佔優勢。

實用主義：選「最適合這個專案的技術」而不是「現在最流行的技術」，這種態度在社群裡越來越普遍。

適合的使用場景

HTMX 比較適合：

  • 內部管理系統
  • 資料導向的應用程式（報表、搜尋、篩選）
  • 需要 SEO 的公開內容網站
  • 規模較小、需要快速交付的專案
  • 後端開發者想自己包辦前端互動的情境

反過來，如果專案需要高度複雜的前端狀態（例如即時協作、複雜的動畫流程、大量的離線操作），HTMX 就不是合適的工具。

取捨

HTMX 不是要取代 React 或 Vue，而是在兩者之間補了一個位置——比純 HTML 表單靈活，比完整 SPA 框架輕。

評估要不要引入時，幾個問題值得先想清楚：專案的互動複雜度到底在哪裡？團隊後端能力強還是前端能力強？部署環境能不能配合後端渲染的架構？這些答案比技術本身更能決定 HTMX 是不是對的選擇。