- 現代のWeb開発では、HTMLか大規模なJavaScriptフレームワークかという誤った二者択一が、開発者を不要な複雑さへ追い込んでいる
- HTMXは、HTML属性だけでAJAXリクエスト、部分更新、アニメーション遷移を扱え、サーバーが返したHTMLをそのまま画面に反映する方式を提供する
- 既存のコードベースを大きく変更せず段階的に導入できる構造で、フロントエンドの複雑さを減らし、生産性と保守性を高められる
- ReactベースのSPAと比べて、コード量・依存関係・ビルド時間・読み込み速度において大きな改善事例が実運用で確認されている
- 過剰なフレームワーク選定よりも、シンプルなハイパーメディアベースのアプローチのほうが、長期的には生産性と保守性に有利である
問題提起: Web開発における誤った選択肢
- Web開発の議論では、HTMLだけを使うかReactのような大規模フレームワークを使うかという極端な選択肢ばかりが繰り返されている
- 素のHTMLはリンク・フォーム・
dialogなど基本機能が強力だが、部分更新や即時的な反応性には限界がある
- React・Vue・Angularを選ぶと、数百もの依存関係、遅いビルド、複雑な状態管理の議論がついて回る
- シンプルなCRUD・ダッシュボード・フォーム中心のアプリにまで、過剰なツール体系が適用されているのが現実
HTMXの中核概念
- HTMXは、HTML要素に特別な属性を追加してサーバーとの非同期通信を行うためのツール
- たとえば
hx-get、hx-post属性でリクエストを送り、レスポンスを特定のDOM領域に挿入する
- すべてのHTML要素がHTTPリクエストの主体になれるよう拡張する
- サーバーはJSONではなくHTML断片をそのまま返し、返されたHTMLを指定位置に自動で置換または挿入する
- JavaScriptを直接書かなくても、HTML属性の宣言だけで動作を定義できる
- ライブラリサイズは約**14kb(gzip)**と非常に軽量
- 別途ビルドツールやフレームワーク設定なしで、既存のHTML文書にそのまま適用可能
- サーバーレンダリング中心の伝統的なWeb開発方式と相性がよい構造
主な機能
- AJAXリクエスト処理: HTML属性だけでGET、POSTリクエストを実行
- DOM更新: サーバーから返されたHTMLを指定要素に自動反映
- イベント処理: クリック、入力などのユーザーイベントに応じてサーバー呼び出しを接続
- 履歴管理: ブラウザの戻る、進む動作と連携
実際の導入事例と数値
- ContexteがReactベースのSaaSをDjango + HTMXへ移行
- コード総行数が67%減少 (21,500 → 7,200)
- JavaScript依存関係が96%減少 (255 → 9)
- ビルド時間が88%短縮 (40秒 → 5秒)
- ページ読み込み速度が50〜60%改善
- コードベースの3分の2を削除し、それでもアプリはより良くなった
- フロントエンドとバックエンドを分けずに、すべての開発者がフルスタック作業可能
よくある反論への整理
- 「複雑なクライアント状態管理が必要なのでは?」
- 実際には多くがフォーム、リスト、クリックで表示される要素程度で、HTMXで十分に処理できる
- Google Docsのようなリアルタイム共同編集ツールなら例外だが、大半はCRUDアプリを過大評価している
- 「Reactエコシステムの利点は?」
- 膨大なエコシステムは、そのまま数GBの
node_modules、終わりのない選択肢、状態管理論争につながる
- HTMXのエコシステムは、選んだサーバーサイド言語ひとつで完結する
- 「SPAのほうが体感速度で速いのでは?」
- 初回は大容量JavaScriptのダウンロード・解析・実行・ハイドレーションをすべて経る必要がある
- HTMXは初期読み込みから速く、その後も変更された部分だけ置き換えるため応答速度を維持できる
- 「特定のReact機能がどうしても必要な場合は?」
- 場合によってはReactが適していることもある
- ただ実際には、問題全体の一部にしか必要ない道具を習慣的に選んでいることが多い
- なぜHTMXを選ぶべきなのか?
- チームが失敗する理由は間違ったフレームワークではなく、過剰なフレームワーク選択にある
- HTMXはシンプルさに賭けるものであり、長期的に見てシンプルさは保守性と生産性で利点をもたらす
HTMXが向かないケース
- リアルタイム共同編集ツール (Google Docs, Figma)
- 大規模なクライアント計算が必要なアプリケーション (動画編集ソフト、CADツール)
- オフラインファースト構成 (もちろん複数のアプローチを組み合わせることもできる)
- 本当に複雑なUI状態を要求する場合
- でも、本当に自分はそういうものを作っているのだろうか?
- ただフォームと表、一覧だけでできた別のダッシュボード、管理パネル、ECサイト、ブログ、SaaSアプリを作っているだけではないか?
- そうしたものに対して、HTMXは本当に驚くほど優れている 「どうしてこんなに複雑に作っていたんだろう?」「今まで時間を無駄にしすぎていた」と言いたくなるほど
だから一度試してみてほしい
- Reactも使った、Vueも使った、Angularは使って後悔もしたのでは?
- 今週Hacker Newsで流行っているメタフレームワークにも、もう一度くらいは触っているはずだ
- HTMXをとにかく一度だけ使ってみてほしい
- 週末の1日を投資して
- サイドプロジェクトをひとつ選ぶか
- 誰もあまり気にしていない内部ツールを選ぶか
- いつか作り直そうと先送りしていた対象を引っ張り出して
<script>タグを1つ追加し、hx-get属性を1つ書いて、実際に動くのを自分で確認してみよう- 最悪でも週末の1日を失う程度で、損は大きくない
- でも気に入らないということはないはずだ
- 実際には、Web開発がなぜここまで複雑だったのか不思議に思うようになるだろう
8件のコメント
去年、こんな発表をしていたんですね。聞いた人はあまりいませんでしたが^^
https://www.slideshare.net/slideshow/htmx-2024/274315966
PoCレベルでこんなものも作っていました
https://github.com/iolo/hx
しかし、誰もhtmxを使わないんですよね（笑）
すでに慣れ親しんだ状況と、それに見合う大規模なエコシステムが構築されたあとに固定化され、もはやイノベーションへの動きがないように見えるのが残念です。
スライドが面白いですね。発表を見られなかったのが残念です（笑）
PyConで関連講演を聞いたことがありますが、講演者の方もまだ実務では使ってみたことがないと言っていたのが印象に残っています。
Rust、お願いだから一度だけ使ってみてください？
Alpine.js を試したことがあるのですが、状態管理はほとんどの場合で必要でした...
最初からバックエンドで状態管理するように設計しない限り、段階ごとの状態や条件付きの状態などを解決するのが厄介だった記憶があります。
言っていることにはすべて共感しますが、htmx にはなかなか手が伸びません…
Hacker Newsの意見
私はhtmxの作者です。大げさな記事のおかげで注目されるのはありがたいですが、こういう形のハイプはあまり好きではありません
Webアプリの作り方はさまざまで、それぞれに長所と短所があります。htmxの強みと弱みはこの記事で整理しています
もう1つの素晴らしいhypermedia志向ライブラリであるUnpolyもぜひ試してみてください
（追記）記事を読み直したら、思ったより悪くありませんでした。それでも htmx はもう少し落ち着いたトーンで扱ってほしいです
ドロップダウンによるフィールド更新、モーダルの生成、自動補完の検索ボックスなど、どれも簡単です
ただし、RIAフロントエンドの複雑さは、データ変更時にフロントエンドをどう更新するかにあります。
バックエンド側で多少の調整が必要で、複数のpartial updateをまとめて扱える構造があるとさらに良いです
今は Rails + Stimulus でサイドプロジェクトをやっていますが、Stimulusはむしろ少し大げさに感じます。InertiaやStimulusをいつ選ぶべきか気になります
Alpine.jsプラグインとして、リンクとフォームに基本的なAJAX機能を追加してくれます
“Hello World”の例でReactより優れていると主張する記事にはうんざりします
単純な例なら何でもうまく動きます。しかし実際には、依存関係の多いバックエンドや複雑なUIがほとんどです
基本デモは良いですが、より複雑な機能を追加するときにどう拡張できるのかを示す必要があります
JSをどこに追加するのか、ビルドステップが必要なのか、htmxのパラダイムにどれほど縛られるのかが気になります
Reactより優れているというより、別のアプローチにすぎません
DOMの一部を置き換えるパラダイムは非常にシンプルで直感的です
例: effect-ts は強力ですが、単純な出力ですら複雑です
私たちのスタートアップはHTMXを導入しましたが、最終的にはReactへ移行しています
HTMXはレスポンス処理の複雑さが高く、各エンドポイントが複数のHTML断片を返す必要があります
ドキュメントや事例が不足していて、大規模向けのベストプラクティスもありません。
Reactは成熟しており、AIコーディングとの相性も良いです。HTMXは単純なプロジェクトには向いていますが、それ以上は難しいです
各エンドポイントは1つの役割だけを担い、Optimistic UIですぐに反応します
エラー処理はシンプルにし、
hx-swap-oobは最小限に使います技術選定で重要なのはトレードオフを最小化することです
だから私はバックエンド検証中心にして、フロントは単に表示だけを担当させます
私はSSRを求めていません。バックエンドはJSON APIだけを提供し、フロントはそれを消費します
SSRは過大評価された概念だと思います。クラウドサービスを売るための誘導戦略のように見えます
Demo 3 Live Search の例は**スクロールの引っかかり（jank）**がかなりひどいです。
結果がドキュメント内に直接挿入されるため、レイアウトが継続的に再計算されているように見えます
Reactは十分に良いです。単純なプロジェクトでも、わざわざ別のパラダイムを学ぶ理由はありません
一方HTMXは15分で概念を理解でき、10年使い続けられます
歴史的に軽量なパラダイムが市場で勝ってきました。Reactもかつてはそういう存在でした
私はHTMXではなくAlpine.jsに完全に惚れ込みました
サーバーレンダリングされたHTMLを**強化（enhance）**するという考え方がしっくりきました
ドロップダウンや表示/非表示など、どれも直感的でビルドステップも不要です
直感的で、大規模プロジェクトでも管理しやすいです
JSをHTMLにインラインで入れていくと保守が難しくなり、状態管理も暗黙的です
HotwireやStimulusの方が組織規模ではずっと良いと感じます
大規模アプリでHTMXを使うなら、サーバー負荷とコストが気になります
HTMLをサーバーでレンダリングするので、JSONより処理量が多いように思えます
JSONシリアライズより効率的な場合も多く、クライアント側にもデシリアライズのコストがあります
HTMXは Alpine.js のようなツールと一緒に使えば、複雑な状態も簡単に扱えます
すべての状況に合うわけではありませんが、多くの場合とてもうまく機能します
フレームワーク布教はWebエコシステムにおける最悪の文化です
良いソリューションなら、いずれ採用されます。わざわざ伝道師のように振る舞う必要はありません
npm攻撃も誇張されています。htmxも結局はnpmを使わざるを得ません
世の中にはマーケティングや知名度によって採用された悪いソリューションがたくさんあります
本当のクラフトマンシップを守るには、こうした偏りに抗う必要があります
HTMXは両方の世界の欠点だけを合わせたもののように見えます
SSRは凝集性があり、CSRは分離された構造ですが、HTMXは両方を混ぜているため暗黙的な結合が生まれます
同じデータを別の形式で表示したい場合、バックエンドで2つのエンドポイントを作らなければならないのか疑問です
ほとんどのアプリはバックエンドの状態だけで十分で、UX向上以外に大きな利益はありません
ページ全体をサーバーで構成するなら、データはすでにその中にあります