</> Htmx – The Fetch()ening

 (htmx.org)
2 ポイント 投稿者 GN⁺ 2025-11-04 | 1件のコメント | WhatsAppで共有
  • htmx 4.0 は、従来の XMLHttpRequest ベースの構造を fetch() 中心の非同期構造へ全面的に置き換える大規模なリビルド版
  • 属性継承方式 は暗黙的なものから :inherited による明示的宣言へ変更され、コードの明確さと保守性が向上
  • 履歴キャッシュ はローカルスナップショット保存の代わりに ネットワークリクエストベースの復元方式へ簡素化され、安定性が強化
  • ストリーミング応答、SSE、DOM morphing, <partial> タグ、View Transition キュー など多様な新機能がコアに統合
  • 長期的には コードベースの単純化と拡張性の改善 を目指し、既存の 2.0 ユーザーも継続サポート予定

htmx 4.0 概要

  • htmx 4.0 は既存構造を全面的に書き直し、fixi.js の開発経験と 5年間の保守運用の教訓を反映
  • 主な変化は fetch() への移行、属性継承の明示化、履歴キャッシュの簡素化という 3つの核心的変更点 に要約される

The fetch()ening

  • XMLHttpRequest を fetch() に置き換え、Ajax インフラを現代化
    • ほとんどのユースケースには大きな影響はないが、イベントモデルは fetch() の非同期特性に合わせて変更
  • この移行は、コードの単純化と今後の機能拡張のための基盤を提供

明示的な属性継承

  • 従来の暗黙的継承の代わりに :inherited 修飾子 を使って明示的に宣言
    • 例: 
      <div hx-target:inherited="#output">
    <button hx-post="/up">Like</button>
    <button hx-post="/down">Dislike</button>
</div>
    • hx-target が明示されていない場合、子要素には継承されない
  • 多くのユーザーにとって 最大のアップグレード変更点

履歴キャッシュの簡素化

  • htmx 2.0 の ローカル DOM スナップショットキャッシュ は、サードパーティによる変更や隠れた状態などのため不安定だった
  • 4.0 では ネットワークリクエストによる復元方式 に変更
    • キャッシュ拡張はオプションの opt-in として提供
  • コードベースの単純化と デフォルト動作の信頼性向上 を実現

維持される要素

  • hx-get, hx-post, hx-target, hx-boost, hx-swap, hx-trigger など 中核 API は同一
  • :inherited の追加以外は、ほとんどのプロジェクトで 既存コードのまま動作可能
  • 長期的な保守性と安定性を強化

アップグレード方針

  • 2.0 ユーザーには アップグレード作業が必要 だが、2.0 は 恒久的にサポート
  • 4.0 は 2.x と並行して配布 され、latest への切り替えは 2027年初頭の見込み
  • 2.0 の挙動を復元する 拡張(extension) も提供予定

新機能の要約

ストリーミング応答と SSE 統合

  • fetch() の Readable Streams サポートを活用し、部分的な DOM 置換 が可能
  • SSE(Server Sent Events) が コア機能として再統合 され、段階的なコンテンツ更新を支援

Morphing Swap

  • Idiomorph アルゴリズム をベースに、DOM マージ時の ノード保持・削除の判断を改善
  • morphInner, morphOuter スワップがコアに含まれる

<partial> タグ対応

  • 従来の Out-of-band swap の複雑な構文を簡素化
  • <partial> はテンプレート要素で、hx-target, hx-swap などの標準属性を使用可能
  • Out-of-band swap は id ベースの単純置換 に回帰

View Transition 改善

  • トランジションキュー(queue) を導入し、視覚的な衝突を防止
  • CSS トランジションは従来方式を維持し、非同期ランタイムで簡素化
  • デフォルトで有効化するかどうかは未定

イベント順序の安定化

  • fetch() ベースの非同期構造により イベント順序の保証が容易
  • 新しいイベント命名規則を導入:
    htmx:<phase>:<system>[:<optional-sub-action>]
    • 例: htmx:before:request

拡張性の強化

  • async ベースで 事前リクエスト(preload) や 楽観的更新(optimistic update) の拡張を提供
  • リクエスト/レスポンス/スワップのサイクルを 拡張開発者に開放 し、fetch() 実装の置き換えも可能
  • ハック なしで望む挙動を実装可能

hx-on 改善

  • 標準化された構文 hx-on:<event name> を採用
  • 非同期 API サポートにより 簡単な DOM スクリプティングが可能 
    <button hx-post="/like"
        hx-on:htmx:after:swap="await timeout('3s'); ctx.newContent[0].remove()">
    Get A Response Then Remove It 3 Seconds Later
</button>
  • eval() 無効化環境でも動作するが、一部機能に制限あり

全体的な方向性

  • htmx 4.0 は 2.0 と似た使用感 を維持しながら、バグ削減と機能向上 を目標とする
  • コードの単純化、明示的な構造、非同期ベースの拡張性により、より安定的でモダンな htmx を提供

開発スケジュール

  • アルファ版(htmx@4.0.0-alpha1) は現在公開中
  • 正式な 4.0.0 リリース は 2026年初頭〜中頃を予定
  • 2027年初頭 に latest へ切り替え予定
  • 開発状況は GitHub の four ブランチおよび four.htmx.org で確認可能

関連記事

1件のコメント

 
GN⁺ 2025-11-04
Hacker Newsの意見

  • 結局考えを変えて、htmxの新しいメジャーバージョンを出すことにしたとのこと
    ただし「3.0は存在しない」という約束を守るため、次のバージョンは htmx 4.0 と命名した
    技術的には正しい表現だとして、冗談交じりの反応を見せている

    • 面白い解決策ではあるが、かつて消えた PHP 6 のようにユーザーの混乱を招くかもしれない
      むしろ正直に 3.0 として出した方がよかったのではないかと思う
    • いっそそのまま htmx 4.1 にして、「xhtmx 1.0」を作ろうという冗談も出ている
    • Leisure Suit Larry 4: The Missing Floppies みたいだという声もある
    • 「3番目のバージョンはない」とは言っていなかったのが幸いで、表現の余地があるという指摘もある

  • htmx 2.0 は恒久的にサポートされる予定で、アップグレードの圧力はまったくないという
    API変更が頻繁な時代に、こうしたアプローチは称賛に値する

  • 安定性を求める人たちは、しばしば誤った教訓を得てしまうと感じる
    Python 3.0 のように大きな変更を一度に詰め込むより、段階的なリリース戦略の方がよいと主張している
    たとえば 2.1、4.0、5.0 などに分けて変更を導入すれば、管理はずっとしやすくなる
    Django のように、複数バージョンにわたって 互換段階を維持する方法 を勧めている

  • hx-target 属性の説明が分かりにくいと感じている
    「inherited」よりも「inheritable」あるいは「inherit」の方が自然に見える

    • 自分は「子が継承する」という意味に読めたので、「pass-down」のような表現の方が明確かもしれないと提案している
    • 「inherited」は誤った単語で、「inherit」は短くてよいという意見もある
      冗談で「bequeath」でもいいと付け加えている
    • いろいろな表現を検討中で、意見を受け入れるつもりだという
    • 「heritable」や「cascade」といった代案も挙がっている

  • HTMX のアイデアと Hypermedia の哲学 は素晴らしいと思う
    SPA 環境から離れて Datastar を選んだが、学習への投資に対して 拡張性 がより大きいと感じている
    サーバーからブラウザへ シグナルを直接プッシュ できるようになり、ポーリング用コードを取り除けたことで、複雑さが大きく減った
    Alpine.js への依存もなくなってコードがシンプルになり、ストリーミングベースの全体ビュー更新 も圧縮のおかげで効率的に動作する
    SPA から来たなら、Datastar と HTMX の両方を試してみることを勧めている

  • fetch() へ移行して Readable Stream を活用する部分が興味深い
    HTMX をかなり使ってきたが、Datastar の SSEベースのストリーミング の方がより魅力的で、最近はそちらを好んでいる

  • HTMX の進化は歓迎しつつも、Datastar の方が 標準により親和的で柔軟な API を提供していると感じている
    小さなパッケージに Fetch、SSE、declarative signals、DOM morphing など多様な機能が入っているという
    そのため「なぜ HTMX を使うべきなのか？」という疑問を投げかけている

    • Datastar Pro は オープンソースではないため、信頼性リスクがあると指摘している
    • Datastar の作者が以前 HTMX にこうした機能を入れようとしていたという 皮肉 にも触れている
    • HTMX は リクエスト/レスポンスのパラダイム に最適化されたシンプルなインターフェースが強みだと説明している
      Datastar はイベントストリーム中心なので、リアルタイムダッシュボードやゲームには向いているが、多くの Web アプリでは HTMX のシンプルさの方が有利だという
      関連参考: Datastar エッセイ, Less HTMX is More
    • HTMX はブラウザの URL履歴管理 を簡単にサポートするが、Datastar はこの機能を有料版（Pro）に限定しているという

  • 「完璧だからもうメジャーバージョンはない」と言っていたのに、結局 進化の必要性 を認めた点を突いている
    「これからイベント命名の標準を変える」という部分を引用し、JavaScript を避けようとする試みを皮肉っている

    • 「結局 JavaScript を使わないようにした結果、カスタム構文 を JS で解釈することになった」と皮肉っている
      それでも HTML で意図を表現できる点は認めている
    • 「今回こそ本当に最後のバージョンになるだろう」という冗談もある
    • 「それでも JavaScript を直接書くよりはましだ」と前向きに受け止める意見もある
    • 「著者の考えが変わったからといって何が問題なのか」と、批判的な口調を指摘する声もある

  • 文章が非常に明快で、API設計の哲学 をよく学べたという

  • fetch と HTMX を併用するために xhr-fetch-proxy を作ったが、
    今回の変更でさらに多くの可能性が開けそうだという
    プロジェクトリンク

    • 4.0 ではリクエストサイクルが完全に開かれていて、リクエストごとに fetch 実装を差し替え られるという
      このアイデアは fixi.js から学んだと付け加えている