先に要点
- htmx は、`hx-get』 `hx-post』のような HTML 属性だけで部分更新やインタラクションを実現する 小さな JavaScript ライブラリ。フロントエンドのフレームワークではなく、HTML を直接拡張する道具。
- サーバは JSON ではなく HTML 断片を返す。`UI の状態はサーバが知っている』 `クライアント側に状態管理を作りすぎない』 という、SPA 一辺倒の流れと逆方向の設計が特徴。
- Rails / Laravel / Django / Phoenix / Go のテンプレートエンジンと相性が良く、`サーバ側で HTML を組み立てる文化』を持つ案件で再評価が進んでいる。`React + REST API は重い』と感じる中小規模 Web で特に効く。
- 万能ではない。` クライアント側で複雑な状態を持つ UI(リッチエディタ、ゲーム、大規模ダッシュボード)』には不向き。`サーバ駆動で十分な UI かどうか』を見極めるのが採用判断の中心。
htmx ってよく聞くけど、React の代わりなの？』 HTML 属性だけで動くって、jQuery と何が違うの？』 `Rails 復権の話と関係ある？』 ── 2023年頃から、SPA フレームワーク疲れの文脈で htmx の名前を見る機会が一気に増えました。
ざっくり言うと、htmx は HTML だけでサーバとの通信を書ける』ようにする小さなライブラリ</strong> です。SPA は重い』 JSON API を作るだけで仕事が倍になる』 状態管理の闇に毎回ハマる』── そんな現場の疲労感に対して、` サーバが HTML を返す古典的な Web の仕組みに、ちょっとだけモダンな部分更新を足す』 というアプローチで応えるのが htmx の立ち位置 です。
この記事では、2026年5月時点の htmx の状況をベースに、何ができるか・React との違い・どこで効くか・どこでは不向きか・採用判断 を、Rails / Laravel / Django などのサーバサイド経験者でも、React 経験者でも追える粒度で整理します。
htmx の核心 — HTML を拡張する小さな JS
htmx の本体は 1ファイルの小さな JavaScript(2026年5月時点で gzip 後 14KB 程度)で、それを読み込むと HTML に `hx-*』属性 が使えるようになります。
<button hx-get="/users/42/profile" hx-target="#profile">プロフィールを開く</button>
<div id="profile">(ここに HTML が差し込まれる)</div>
このボタンを押すと、ブラウザは /users/42/profile』に GET リクエストを送り、返ってきた HTML 断片を #profile』要素の中に差し込む という挙動になります。
`JavaScript を1行も書かずに部分更新ができる』のが、htmx の体験を一言で表す部分です。
代表的な属性
`hx-get』 `hx-post』 `hx-put』 `hx-delete』(HTTP メソッド)、`hx-target』(差し込み先)、`hx-swap』(差し込み方)、`hx-trigger』(発火条件)、`hx-vals』(送信値)。これだけ覚えれば多くの UI は組める。
サーバが返すもの
JSON ではなく HTML 断片。`プロフィールカードの HTML』 `テーブル行の HTML』 `モーダルの中身の HTML』など、`そのまま挿入できる形』で返す。
SPA を作るために生まれた』のではなく、<strong> SPA を作らずに済むようにするための仕組み』 と捉えると、htmx の存在意義が見えてきます。
ハイパーメディア駆動 — HATEOAS の現代的解釈
htmx の思想的な背景は、`HATEOAS』(Hypermedia As The Engine Of Application State)という Web 本来の設計哲学を、現代的に再解釈したものです。
古典的な Web の発想
` 次に何ができるか』はサーバが返した HTML に含まれている。`このユーザーは編集できるか』 `削除できるか』はサーバが UI に書き込んで返す。クライアントは深いことを知らない。
htmx が戻す視点
サーバが HTML(= 次のアクションを内包したハイパーメディア)を返す形に戻すと、`今できることはサーバが決めて、クライアントはそれを表示するだけ』にできる。
昔の Web に戻る』のではなく、<strong> Web 本来の強みを現代的な道具で取り戻す』 というのが htmx の哲学です。
このあたりは作者の Carson Gross が公開している Hypermedia Systems という無料書籍に詳しくまとまっています。
React / SPA との比較
React で書くこと』と htmx で書くこと』を並べると、何が違うかが立体的に見えます。
| 軸 | React + REST API | htmx + サーバサイド |
|---|---|---|
| 状態の場所 | クライアントとサーバの両方で持つ | 主にサーバ。クライアントは表示専門 |
| サーバが返すもの | JSON | HTML 断片 |
| 必要なフロント実装 | コンポーネント / hooks / 状態管理 / ルーティング | テンプレート(blade / erb / jinja 等) + 少しの hx-* |
| JS フットプリント | 大きい(数百KB 〜 MB) | 小さい(htmx 本体 14KB 程度) |
| 権限ロジック | サーバとフロントで二重に書きやすい | サーバ側に集約しやすい |
| 得意な UI | リッチで動的、複雑な状態の SPA | CRUD、業務系、コンテンツサイト |
| 不得意な UI | シンプルな業務 UI(オーバーキル感) | リッチエディタ、リアルタイム、ゲーム |
要点は どこに複雑性を置くか』の選択</strong> です。 React はクライアントに複雑性を引き取って、サーバを薄くする』、htmx は `サーバに複雑性を残し、クライアントを薄くする』。どちらが正解ではなく、業務の性質と既存のスタックに合うほう を選ぶ、という構図になります。
どこで効くか — htmx 向きの案件
実務で htmx が `効く』場面を整理します。
①業務系 Web アプリ
社内ツール、管理画面、CRM、入力フォーム中心の業務システム。`画面遷移 + フォーム送信』の世界で、SPA 化のコストに見合わないケースが多い。
② コンテンツサイト / メディア
ブログ、ニュース、ドキュメントサイトのような `読む』中心の UI。`いいねを押すと色が変わる』程度の動きは htmx で十分。
③ Rails / Laravel / Django の既存案件
サーバ側で HTML を組み立てる文化が既にある。`React 化のために API を二重実装』するコストを払わずに、現代的な UX に近づけたいケース。
④ 個人開発 / スタートアップの初期
小さいチーム / 1人開発 では、`フロントとバックを別人格で持つ』のはオーバーヘッド。htmx で `1人開発の総工数を縮める』効果が大きい。
シンプルな CRUD + ちょっとした非同期』で済む UI のかなりの部分は、htmx で十分実装できます。 特に <strong> SPA にしたが大して使いこなしていない案件』 ほど、htmx 化のリターンが大きい印象です。
どこで詰まるか — htmx の限界
逆に、htmx が向かないケースもはっきりしています。
①複雑なクライアント側状態
巨大フォームの動的バリデーション、リッチテキストエディタ、グラフィカルなフローエディタ ─ こうした `クライアントが状態を持たないと話にならない』UI は React / Vue / Svelte の領分。
② オフライン対応 / PWA
htmx はサーバ前提なので、`オフラインでも動く UI』は構造的に苦手。PWA + Service Worker 前提の案件は別アプローチが必要。
③ ネイティブアプリと UI を共有したい
React Native などで `モバイルと同じコンポーネントを Web でも使いたい』案件では、HTML 断片を返す htmx 系では合わない。
htmx だと書けないわけではない』が、書ける範囲を超えると無理が出やすい』というのが正確な表現です。
` UI 全体の複雑さの真ん中に、クライアント状態がガッツリ存在するかどうか』 が、採用可否の一番大きな判断軸になります。
Rails / Laravel / Django との相性
htmx は サーバ側で HTML を組み立てるフレームワーク と非常に相性がよく、特に Rails / Laravel / Django の案件で再評価が進んでいます。
Rails + Turbo / Stimulus との関係
Rails 公式の Hotwire(Turbo / Stimulus)も `HTML over the wire』の思想で htmx と近い。`Rails ならまず Hotwire、それ以外なら htmx』 という棲み分けが現実的。
Blade テンプレートで HTML 断片を返すコントローラを作るだけ。Inertia / Livewire / htmx の3択になりがちで、`軽さ重視なら htmx』 が選ばれる。
SPA + REST API』 が標準だった2010年代の流れに対して、サーバが HTML を返す』 系がじわじわ復活していて、その代表的なライブラリの1つが htmx、というのが2026年現在の景色です。
AI 時代の htmx 観
AI 時代に htmx が再評価される文脈もあります。
AI でコードを生成しやすい
`HTML + サーバテンプレート』 はテキストとしてシンプルで、LLM が出力しやすい / 読みやすい構造。`React のコンポーネントツリーを把握させる』より低コスト。
小さなアプリを爆速で立てたい
AI で素早くプロトタイプを作るときに、`SPA を立てる手間』 を省略できる。v0 で UI のたたき台を作る ような流れと、`そのまま手早く動かす』選択肢として並ぶ。
サーバ駆動 UI と AI
` ChatGPT のような UI』 は実は htmx と相性が良い。`サーバが次に表示する HTML を返す』 という発想で、AI チャットや AI ワークフロー UI を素直に作れる。
フロント実装の `軽量化』 圧力
AI で開発スピードが上がるほど、`重い SPA を作る労力に見合うか』 が問われる。`軽い htmx で済むなら htmx』 という判断が経済的に成立しやすくなる。
React か htmx か』 ではなく、<strong> どの UI を htmx で、どの UI を React で書くか』 を意識して選ぶ時代 に入りつつあります。
すべてを SPA で書く時代は徐々に終わり、` 道具を使い分ける成熟期』 に入っている、というのが大きな流れです。
htmx に関するよくある質問
Q. htmx と jQuery の違いは何ですか？
A. jQuery は 任意の DOM 操作を JS で書きやすくする汎用ライブラリ』、htmx は <strong> HTML 属性で部分更新を宣言する専門ライブラリ』です。jQuery は 何でも書ける』 反面、コードが散らかりやすい。htmx は できることが意図的に絞られている』 ので、HTML がそのまま設計図になります。
Q. React を学ばずに htmx だけで仕事できますか？
A. 業務系 / 管理画面中心の案件であれば十分に可能です。 業界全体では React 系のスキルも依然として必須に近い</strong></strong> ので、htmx も覚える』 か `React + htmx 両方の使い分けができる』 立ち位置を目指すのが、キャリア上の柔軟性を保ちやすいです。
Q. SEO に htmx は不利ですか？
A. むしろ 有利に働くことが多い です。サーバが HTML をフルレンダリングして返すモデルなので、SSR / SSG と相性が良く、クローラに優しい』 状態を作りやすい。SPA の JS を実行しないと中身が見えない』 問題と無縁です。
Q. 認証 / 認可はどう扱いますか？
A. サーバ側で従来通りに扱う のが基本です。セッション Cookie + サーバ側のロールチェック』 という Web 標準のやり方で十分。API トークンと JWT をクライアントで管理する』 という SPA 的な複雑さを抱える必要が少ないのも htmx の利点です。
Q. JavaScript で複雑な処理を書きたいときはどうしますか？
A. htmx は他の JS ライブラリと併用しやすい設計です。Alpine.js』 のような小さな状態管理ライブラリ、または必要箇所だけ vanilla JS / Hyperscript を使うのが定番です。巨大な状態管理が必要』 ならその時点で `React の方が向く』 と判断するのが健全です。
Q. htmx でリアルタイム更新はできますか？
A. できます。Server-Sent Events(SSE)』 や WebSockets』 のサポートがあり、hx-sse』 hx-ws』 属性で実装できます。チャット / 通知バッジ / リアルタイム集計などは、軽量実装で十分対応できる範囲です。
Q. テストはどう書きますか？
A. サーバ側のテスト が中心になります。/users/42/profile が期待した HTML 断片を返すか』 を統合テストで確認すれば、UI の正しさはほぼ担保できます。E2E テスト(Playwright / Cypress)』 で `クリック → 部分更新が反映される』 ところまでカバーすれば十分なケースが多いです。
参考リンク
- htmx: 公式サイト
- htmx: Documentation
- htmx: Examples
- Carson Gross: Hypermedia Systems(無料書籍)
- Hotwire(Rails): 公式
- django-htmx: GitHub
- Alpine.js: 公式