TITLE

htmx 4.0.0リリース — 属性継承・イベント名・通信方式・履歴管理を変える破壊的アップデート

投稿日：2026.08.30

コミュニティ主導のライブラリが、根幹を4つ同時に変えた

htmxはBig Sky Softwareが運営し、「the htmx team」として複数の貢献者がクレジットされているコミュニティ主導のオープンソースプロジェクトです。特定企業が独占するプロダクトではなく、多くの貢献者の手で育ってきた経緯があります。

そのhtmxの4.0.0で目に入るのは、新機能よりも先に「壊れる」側の変更です。属性の継承ルール、イベント名の形式、内部の通信方式、履歴管理の挙動——htmx 2.xのアプリケーションが暗黙のうちに前提にしていた4つの領域が、今回同時に変わっています。

htmx 2.x から 4.x への4つの破壊的変更(属性継承・イベント名・通信の実装・履歴管理)を比較した表

属性の継承が「暗黙」から「明示」に変わった

htmx 2では、親要素に付けた属性が子要素へ暗黙的に継承される仕組みがありました。たとえば親要素に hx-confirm を指定すると、子要素の hx-get や hx-post によるリクエストにも自動的に確認ダイアログが効いていました。htmx 4ではこの暗黙の継承が廃止され、:inherited というサフィックスを明示的に付けた属性だけが子要素へ継承されます。先ほどの例であれば、hx-confirm:inherited="Are you sure?" のように書き直す必要があります。

この変更は、コードを読むだけでは「どの属性が子に効いているか」が分からなかったhtmx 2の弱点への対応と読み取れます。一方で、既存のhtmx 2アプリケーションが暗黙の継承に依存している箇所は、書き換えないまま4.0に上げると挙動が変わります。

イベント名が体系立った命名規則に変わった

htmx 2のイベント名は htmx:beforeRequest htmx:afterSwap のような、キャメルケースの単一階層でした。htmx 4では htmx:phase:action[:sub-action] という階層形式に統一され、htmx:beforeRequest は htmx:before:request に変わります。

エラー関連のイベントも整理されました。多くのエラーイベントが htmx:error に統合され、HTTPエラーレスポンスは新設の htmx:response:error で発火するようになります。従来の htmx:xhr:* イベント群は削除されました。フォームバリデーション関連の htmx:validation:* イベント群も削除され、ブラウザ標準のフォームバリデーションを使う設計に置き換わっています。

イベント名をリッスンしているJavaScriptコードを持つアプリケーションでは、この命名変更がそのままリスナーの発火漏れにつながります。

通信の配管と履歴管理も入れ替わった

内部の実装も変わりました。htmxがリクエストを送る際の実装は、XMLHttpRequestからfetch()へ配管ごと交換されています。

履歴管理の方式も変更されています。htmx 2は、ブラウザの戻るボタン操作に備えてページのスナップショットをlocalStorageにキャッシュする方式を取っていました。htmx 4ではこのキャッシュ方式を廃止し、戻るボタンが押された時点でページを再取得する方式に変わっています。

新機能と、移行にあたって押さえる配布上の材料

破壊的変更に加えて、新機能も入っています。DOMの差分更新をスムーズにする組み込みのMorph swaps、部分更新の対象をより明確に指定する <hx-partial> 要素、preload・download・Alpine.js互換などの新しい拡張機能が追加されました。属性継承の書き換えを支援する移行用のコマンドラインツールに加えて、htmx 2プロジェクト全体で移行が必要な箇所を検出するアップグレードチェッカーも提供されています。移行を支援するツールボックスとファイルのイラスト

配布面では、htmxに3.xという一般リリースは存在せず、2.xから4.xへ番号が飛んでいます。公式の移行ガイドもhtmx 2.xからの移行を前提にしています。また、htmxはnpmパッケージとunpkg経由のCDNで配布されており、リリース時点でnpmのlatestタグは2.xを指したままで、4.0はnextタグで提供されています。既存プロジェクトで npm install htmx.org を実行しても、タグを明示的に指定しない限り4.0は入りません。

まとめ

htmx 4.0.0が示しているのは、UIライブラリの規模の小ささと、変更が及ぶ範囲の大きさは別軸だということです。属性の継承・イベント名・通信の実装・履歴管理という、アプリケーションが暗黙のうちに前提にしていた4か所が同時に動いた以上、2.xのまま使い続けるか4.xへ移行するかは棚上げにできる話ではありません。

今日からできる一歩は、自社のhtmx 2.xアプリケーションの中から、:inherited を付けずに親属性の継承に頼っている箇所と、htmx:beforeRequest のようなキャメルケースのイベント名をリッスンしている箇所の2つを洗い出すことです。この2つは今回の変更の中でも、書き換えないと確実に挙動が変わる箇所にあたります。洗い出しが終わってから、公式の移行ガイドとアップグレードチェッカーを使った移行作業に進むと、手戻りが少なくなります。