Htmxチームは2026年8月28日、htmx 4.0.0のリリースを発表した。この更新は、ライブラリ内部の通信モデルとイベントシステムを変更する一方、アプリケーションレベルの動作の大部分を2.x系に近い状態に保つことを目指した、大規模なアーキテクチャ改訂と位置付けられている。
プロジェクトのリリース発表によると、htmx 4の開発には約8カ月を要し、より新しいブラウザーの基本機能、特にFetch APIと非同期プログラミングのパターンを用いた作業から発展した。以前のバージョンのhtmxは、主に後方互換性を理由としてXMLHttpRequestを使い続けていた。Fetchへの移行は新リリースの最も明確な技術的特徴の一つだが、メンテナーは、エンドユーザーにとっては大部分が意識されない変更になると見込んでいる。
チームはまた、属性の継承をめぐる、より目に見える破壊的変更を強調した。htmx 2では、多くの属性がデフォルトで継承され、親要素で定義された動作を子要素に引き継ぐことができた。メンテナーによると、このモデルは強力だったが、挙動を論理的に把握するのが難しいことが多かった。htmx 4では継承は自動ではなくなり、開発者は継承される動作を明示的に指定する必要がある。プロジェクトは、これが移行における最大の負担となる可能性が高いと説明し、新しい継承マーカーを追加したり、従来のイベント名を更新したりする必要がある箇所を見つけるため、コマンドラインのアップグレードチェッカーを提供すると述べた。
もう一つの大きな再設計はイベントだった。発表によると、htmx 2のイベントは時間の経過とともに自然発生的に積み重なり、一貫したシステムとして理解するのが難しくなっていた。htmx 4では、イベントをより明確な命名パターンである`htmx:phase:action[:sub-action]`に統一し、属性やJavaScript内に埋め込まれた古いイベント参照を特定するツールを提供する。
履歴の処理も変わる。htmx 4はlocalStorageからページのスナップショットを復元する代わりに、戻る操作の際にページを再取得し、それを文書または指定された履歴要素へ差し込む。メンテナーは、サードパーティー製JavaScriptが、変更をもともと生成した実行時ロジックを保持しないまま、キャッシュされたDOMスナップショットを変更した場合に生じる一連のバグを、この方式なら回避できると主張した。クライアント側ストレージを引き続き使用したい開発者向けには、チームがsessionStorageを基盤とする別個の履歴キャッシュ拡張機能を提供する。
リリース発表では、モーフィング・スワップの組み込みサポートを含む、さらに二つの機能が特に強調された。提供された抜粋には全詳細が含まれていないものの、より大きな全体像は明確だ。htmx 4は、内部を近代化し、ほかのスクリプト手法との連携を円滑にしながら、メンテナーの表現による「100年続くウェブサービス」としてhtmxアプリケーションを存続可能にすることを意図した、長期的な更新と位置付けられている。
プロジェクトは展開も慎重に進めている。チームによると、バージョン4.0はnpm上ですぐにデフォルトの「latest」リリースにはならない。バージョン指定のないCDN URLを利用するユーザーにアップグレードを強制したくないためだ。その代わり、当面は2.x系がデフォルトとして維持され、4.0は2027年初頭のいずれかの時点までnextトラックにとどまる。したがって、2026年8月28日のリリースは、公開であると同時に段階的な移行計画でもあった。ひそかに取り込ませるのではなく、慎重に採用されることを意図した、大規模な新ブランチだ。このため、このリリースはコード上の変更点だけでなく、メンテナーが移行期間をいかに慎重に管理しようとしているかという点でも注目に値する。
