先に要点
- 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 だけでサーバとの通信を書ける」ようにする小さなライブラリ です。 「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 を作るために生まれた」のではなく、SPA を作らずに済むようにするための仕組み と捉えると、htmx の存在意義が見えてきます。
ハイパーメディア駆動 — HATEOAS の現代的解釈
htmx の思想的な背景は、「HATEOAS」(Hypermedia As The Engine Of Application State)という Web 本来の設計哲学を、現代的に再解釈したものです。
古典的な Web の発想
「 次に何ができるか」はサーバが返した HTML に含まれている。「このユーザーは編集できるか」 「削除できるか」はサーバが UI に書き込んで返す。クライアントは深いことを知らない。
htmx が戻す視点
サーバが HTML(= 次のアクションを内包したハイパーメディア)を返す形に戻すと、「今できることはサーバが決めて、クライアントはそれを表示するだけ」にできる。
「昔の Web に戻る」のではなく、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(オーバーキル感) | リッチエディタ、リアルタイム、ゲーム |
要点は 「 どこに複雑性を置くか」の選択 です。 React は 「クライアントに複雑性を引き取って、サーバを薄くする」、htmx は 「サーバに複雑性を残し、クライアントを薄くする」。どちらが正解ではなく、業務の性質と既存のスタックに合うほう を選ぶ、という構図になります。
どこで効くか — htmx 向きの案件
実務で htmx が 「効く」場面を整理します。
①業務系 Web アプリ
社内ツール、管理画面、CRM、入力フォーム中心の業務システム。「画面遷移 + フォーム送信」の世界で、SPA 化のコストに見合わないケースが多い。
② コンテンツサイト / メディア
ブログ、ニュース、ドキュメントサイトのような 「読む」中心の UI。「いいねを押すと色が変わる」程度の動きは htmx で十分。
③ Rails / Laravel / Django の既存案件
サーバ側で HTML を組み立てる文化が既にある。「React 化のために API を二重実装」するコストを払わずに、現代的な UX に近づけたいケース。
④ 個人開発 / スタートアップの初期
小さいチーム / 1人開発 では、「フロントとバックを別人格で持つ」のはオーバーヘッド。htmx で 「1人開発の総工数を縮める」効果が大きい。
「シンプルな CRUD + ちょっとした非同期」で済む UI のかなりの部分は、htmx で十分実装できます。 特に 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 か」 ではなく、「 どの UI を htmx で、どの UI を React で書くか」 を意識して選ぶ時代 に入りつつあります。 すべてを SPA で書く時代は徐々に終わり、「 道具を使い分ける成熟期」 に入っている、というのが大きな流れです。
htmx に関するよくある質問
Q. htmx と jQuery の違いは何ですか？
A. jQuery は 「任意の DOM 操作を JS で書きやすくする汎用ライブラリ」、htmx は HTML 属性で部分更新を宣言する専門ライブラリです。jQuery は 「何でも書ける」 反面、コードが散らかりやすい。htmx は 「できることが意図的に絞られている」 ので、HTML がそのまま設計図になります。
Q. React を学ばずに htmx だけで仕事できますか？
A. 業務系 / 管理画面中心の案件であれば十分に可能です。` 業界全体では React 系のスキルも依然として必須に近い ので、「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: 公式