每日突破性工具推薦｜htmx 4

為什麼今天推薦它

htmx 4 是近期值得關注的前端框架重大版本之一。它於 2026 年 8 月 28 日正式發布，歷經約 8 個月開發。這次更新沒有把 htmx 變成更大型的 SPA Framework，反而繼續深化 Hypermedia-first 路線：讓伺服器直接回傳 HTML，瀏覽器依靠 HTML attributes 描述請求、替換與互動。

真正值得注意的是，htmx 4 在保持使用者層 API 相對熟悉的同時，大幅重構底層：從 XMLHttpRequest 遷移到 Fetch API、內建 DOM morphing、重新設計 extension hooks、加入更完整的 streaming HTML 能力，並重新思考 attribute inheritance 與 history restoration。

工具定位與適用情境

htmx 是一套 dependency-free 的 Hypermedia UI Library。它讓 HTML 元素可以直接發送 HTTP 請求、接收 HTML response，再將 response swap 到指定 DOM 區域。

因此它特別適合：

• Server-rendered Web Application
• 後台管理介面與 CRUD 系統
• Django、Rails、Laravel、Spring、ASP.NET、Go 等 Server-side Framework
• 希望減少前端 JavaScript 狀態管理的專案
• HTML-first、Progressive Enhancement 或 Hypermedia-driven Architecture
• 不需要完整 SPA Client Runtime，但仍希望具有局部更新與即時互動的產品

突破性重點

1. XMLHttpRequest → Fetch API

htmx 4 將核心 HTTP implementation 從 XMLHttpRequest 遷移至現代 Fetch API。

這不只是 API replacement。Fetch 的 async model 讓 htmx 能重新設計 extension system，也為 streaming response、下載與其他現代瀏覽器能力建立更乾淨的底層基礎。

2. Morphing Swap 正式內建

過去若希望更新 DOM 時保留既有節點、focus 或 component state，通常需要 Idiomorph 等 extension。

htmx 4 將 morphing swap 直接整合進核心 distribution。Server 可以繼續回傳 HTML，但 Client 不一定需要粗暴地 replace 整個 target，而能比較既有 DOM 與新 HTML 後進行結構更新。

這使 Hypermedia UI 更接近現代 Reactive UI 的更新體驗，卻不需要建立 Virtual DOM 或大型 Client State Tree。

3. Streaming HTML 成為一等能力

htmx 4 的 extension ecosystem 提供：

• hx-sse：Server-Sent Events
• hx-ws：WebSocket
• hx-multipart：multipart/mixed streaming

這讓 Server 可以逐段送出 HTML fragment，而不是一定要等待整個 response 完成。

對 AI streaming、長時間工作、即時 dashboard、notification feed 等場景尤其有價值。

4. <hx-partial>：一個 response 更新多個區域

新的 <hx-partial> 可以讓一次 server response 描述多個 DOM target 的更新，比傳統 out-of-band swap 更明確。

這很符合 Hypermedia 架構的核心思想：伺服器傳回的是「下一個 UI state 的 representation」，而不是 Client 收到 JSON 後再自行重建 UI state。

5. Attribute inheritance 改成 Explicit-by-default

htmx 2 的部分 hx-* attributes 預設會沿 DOM tree 繼承。雖然方便，但大型 template 很容易出現隱性的行為來源。

htmx 4 改成必須明確使用 :inherited 才會繼承，例如：

<div hx-confirm:inherited="Are you sure?">
  <button hx-delete="/item/1">Delete</button>
</div>

這會增加 migration 成本，但換來更好的 local reasoning：看到 element 時，更容易知道它的行為從哪裡產生。

6. Event lifecycle 標準化

舊版事件名稱長期演化後並不一致，例如 htmx:beforeRequest、htmx:afterSwap。

4.0 統一成：

htmx:phase:action[:sub-action]

例如：

htmx:before:request
htmx:after:request
htmx:before:swap
htmx:after:swap

對 extension、debugging、observability 與大型專案維護都更清楚。

7. History restoration 不再預設依賴 localStorage snapshot

htmx 2 會將頁面 snapshot 放進 localStorage，但第三方 JavaScript 對 DOM 的 mutation 可能一起被保存，導致回上一頁時出現「DOM 已恢復、JS runtime state 卻沒有恢復」的不一致。

htmx 4 預設改成 navigation restore 時重新取得頁面並 swap；需要 client-side history cache 的專案則可選擇 hx-history-cache extension。

這是用更多 network revalidation 換取更簡單、一致的 state model。

核心架構與運作方式

典型 htmx 4 request loop 可以簡化為：

HTML element + hx-* attributes
        ↓
Browser event
        ↓
htmx request pipeline
        ↓
Fetch API
        ↓
Server endpoint
        ↓
HTML / streaming HTML response
        ↓
Swap / Morph / hx-partial
        ↓
DOM becomes next UI state

它與 React 類 SPA 最大的架構差異是：

SPA
Server → JSON → Client State → Components → DOM

htmx
Server → HTML → DOM

htmx 將 UI state representation 的主要責任重新放回 Server，因此可以移除大量 API DTO、Client Store、Data Fetching Layer 與 Client-side Routing Glue Code。

主要優勢

Server 與 UI 的距離非常短

Server handler 可以直接回傳 partial HTML，不必另外建立 JSON API，再讓 Client component 將 JSON 轉換成 UI。

JavaScript Bundle 很小

htmx 本身是單一、dependency-free JavaScript library，也不要求 Node.js build pipeline 才能使用。

Backend 技術幾乎完全自由

只要 Server 能回傳 HTML，就能與 htmx 配合。因此它不是 JavaScript backend 專屬方案。

Progressive complexity

簡單頁面只需要幾個 hx-* attributes；真正需要即時更新時，再加入 SSE、WebSocket、streaming 或 client scripting。

更符合 Web 原生模型

HTTP、HTML、URL、Browser History 與 Form 仍然是主要 abstraction，而不是把瀏覽器轉換成另一套 application runtime。

相較同類方案的優點

對 React / Vue / Svelte

htmx 最大優勢不是 component abstraction，而是可以直接消除許多 client-side state 與 API plumbing。

如果 UI 本質上主要是 server data 的 representation，這通常能顯著降低架構複雜度。

對 Turbo / Hotwire

兩者都屬 Hypermedia-oriented 工具，但 htmx 更偏向 attribute-driven interaction primitives，對任意 backend framework 的依賴更低；開發者可以非常細緻地控制 request trigger、target 與 swap behavior。

對傳統 Server-side Rendering

htmx 保留 SSR 的簡單 mental model，同時補上局部更新、morphing、streaming、SSE 與 WebSocket，因此不必為了少量動態需求直接升級成完整 SPA Architecture。

缺點與限制

1. 不適合高度 Client-state-driven Application

如果產品核心是大量離線狀態、Canvas、複雜 drag-and-drop、即時 collaborative editor 或高度 client-side computation，React、Vue、Svelte 等 Client Framework 通常更自然。

2. Server request 次數可能增加

把更多 state transition 放回 Server，代表互動可能需要更多 round trip。Latency 高的環境需要 caching、preload、optimistic UX 或合理的 local scripting 配合。

3. 4.0 是 Major Migration

Attribute inheritance、event names、extension API 與部分舊 API 都有 breaking changes。官方因此提供 upgrade-check CLI 與 htmx-2-compat compatibility extension，但既有大型 htmx 2 專案仍應先測試再升級。

4. 4.0 尚未成為 npm latest

官方刻意讓 2.x 繼續保持 npm latest，4.0 暫時維持 next，預計到 2027 年才切換，避免使用未鎖版本 CDN URL 的既有網站意外升級。

這不是 4.0 未正式發布；4.0.0 已是正式版本，但官方採取非常保守的 ecosystem migration 策略。

5. Hypermedia Architecture 需要不同思考方式

習慣 SPA 的團隊可能會下意識把 JSON API、Global Client Store 與 Component State 全部搬回來，最後得到兩套架構疊在一起。

htmx 真正的價值通常只有在接受 Server-driven Hypermedia 設計後才會完整呈現。

適合哪些使用者與專案

推薦給：

• Backend-heavy Full-stack Developer
• Django / Rails / Laravel / Spring / ASP.NET / Go Web 團隊
• CRUD、Dashboard、CMS、Internal Tool、SaaS 管理介面
• 希望降低 SPA complexity 的小型與中型團隊
• 重視 HTML、HTTP 與 Progressive Enhancement 的開發者
• 想建立 Server-driven AI streaming UI 的專案

不適合哪些使用者與專案

不建議作為主要 UI architecture 的情況包括：

• Figma 類高度互動式編輯器
• 大量離線運算與 local-first state
• 遊戲或 Canvas-heavy Application
• 極度依賴 Client Component Ecosystem 的產品
• 已有成熟大型 SPA 且沒有實際 complexity problem 的團隊

結論

htmx 4 的突破性並不是加入更多 JavaScript abstraction，而是反方向證明：現代 Web UI 不一定需要把 Application State 全部搬到 Client。

Fetch-based core、內建 DOM morphing、streaming HTML、<hx-partial>、重新設計的 extension hooks，以及更明確的 inheritance 與 history semantics，使 htmx 從「用 HTML attributes 做 AJAX」進一步成為更完整的 Hypermedia Application Runtime。

如果專案主要由 Server Data、Form、CRUD、Navigation 與局部即時更新組成，htmx 4 是近期非常值得重新評估的前端架構選擇。

今天推薦它的原因也很明確：4.0.0 才剛於 2026 年 8 月 28 日正式發布，目前仍處於新 major version 的 ecosystem migration 階段，而且這次改版直接觸及 HTTP transport、DOM update、streaming、extension API 與 state restoration 等核心架構，而不是單純增加表層功能。