htmxは一言で言うと、HTMLに属性を足すだけで「部分更新」「非同期送信」「画面遷移っぽい動き」を作れるライブラリです。SPAのために巨大なフレームワークを抱えなくても、必要なところだけサクッと動かせる。こういう立ち位置。
リンクをクリックしたら一部だけ差し替える。フォーム送信したらその場で結果を返す。読み込み中はローディングを出す。これらを、HTML側の指定で寄せていく発想です。サーバがHTMLを返せば、そのまま画面に入る。HTMLが主役。そこが気持ちいい。
そして今の時代、UIは増えがちです。会社の問い合わせフォーム、管理画面、検索、フィルタ、いいね、コメント、予約。全部をSPAで作る必要はない。むしろ、必要な所だけ速くしたい。そこでhtmxが刺さるわけです。
最近の動き: htmx 2系という現実
2026年版の話をするなら、htmxは2系が前提になりつつあります。unpkgのパッケージ一覧では「latest」が2.0.8になっているので、導入時に2系を引く人が増えるはずです。まあ、いきなりlatestで入れる人もいれば、既存案件は1系で止まっていることもある。現場は混ざります。
1系から2系への移行には互換拡張が用意されていて、htmx-1-compatという拡張で移行を助ける設計になっています。こういう逃げ道があると、既存サイトに入れる時も心理的に楽です。
なぜ今htmxを選ぶのか: いったん落ち着いて考える
フロントエンドの仕事って、気付くと「ビルド」「状態管理」「ルーティング」「キャッシュ」「バンドルサイズ」「SSR/CSR」みたいな話に飲まれがちです。もちろん必要な現場もある。でも、全部の案件にそのフルセットを持ち込むと、開発と運用の負債が増える。
htmxは、そこをスパッと割り切ります。サーバがHTMLを返す。フロントは差し替える。これだけ。だから、チームにバックエンドが強い人がいる現場や、WordPressやCMSベースのサイト、社内ツール、コンテンツ中心のサイトと相性が良い。
JavaScriptをゼロにしろという話でもないです。必要なら書けばいい。けど「書かなくていいところは書かない」というだけで、体感のスピードが上がる。バグの種類も減る。地味に効きます。
でも本当に必要? まずは2つだけ確認
質問していいですか。あなたのページは、データ取得と描画を全部ブラウザ側で抱える必要がありますか。
もう一つ。画面の一部をHTMLで返して差し替える形にすると、実装が楽になりそうですか。
この2つがYESなら、htmxは候補に入ります。逆に、オフライン前提のリッチアプリや、クライアント側で超複雑な状態同期が必要なら、別の道もある。向き不向きはあります。
htmxで出来ること: よく使う機能だけで十分強い
全部覚えなくていいです。現場で効くのは、だいたいこの辺です。
部分更新: hx-getでHTMLを差し替える
htmxの基本は、要素にhx-getなどを付けて、サーバが返すHTMLをDOMに挿入すること。例えばボタンを押したら、右側の一覧だけ更新する、みたいなやつです。hx-getは指定したURLへGETし、そのレスポンスを要素に反映させます。
<button
hx-get="/users?page=2"
hx-target="#userList"
hx-swap="innerHTML">
次のページ</button>
<div id="userList">
<!-- ここが差し替わる -->
</div>;
フォームの非同期送信: hx-postで送って、その場で返す
フォーム送信の体験を上げるなら、hx-postが手堅い。POSTして、返ってきたHTMLを指定先に入れるだけ。成功メッセージだけ差し替えるのもできるし、バリデーション結果のHTMLを返してフォーム付近に表示するのも簡単です。hx-postはフォーム送信を非同期化する代表格。
<form
hx-post="/contact"
hx-target="#result"
hx-swap="innerHTML">
<label>メール</label>;
<input type="email" name="email" required>
<label>内容</label>
<textarea name="message" required></textarea>
<button type="submit">送信</button>
</form>
<div id="result"></div>
どこに入れるか: hx-targetで差し込み先を決める
「自分自身を差し替える」だけでなく、「別の要素に入れる」が欲しい。そこでhx-target。ターゲットをCSSセレクタで指定して、そこを更新します。これがあるだけで、UIの組み立て方が一気に変わる。
どう差し替えるか: hx-swapで挿入方法を制御する
innerHTMLだけじゃなく、outerHTMLで丸ごと置き換えたり、beforeendで追加したりできます。差し替えの仕方を変えるだけで、無限スクロール風にも、差し込み広告にも、通知トーストにも寄せられる。hx-swapは地味だけど便利です。
リンクもフォームもまとめて加速: hx-boostというショートカット
ページ遷移を「フルリロード」ではなく「差し替え」に寄せたい時、hx-boostが効きます。リンクやフォームをブーストして、よりスムーズなナビゲーション体験にする発想。サイト全体をSPAっぽくしたいが、SPAにはしたくない。この矛盾を雑に解決してくれます。
いつ発火させるか: hx-triggerでタイミングを変える
クリックだけでなく、change、keyup、load、intersection的な使い方まで、発火タイミングの指定で遊べます。検索のサジェストや、フィルタの自動更新、一定時間で自動保存。こういう「小さな気の利き」を入れるのに向きます。
ローディング表示: hx-indicatorで待ち時間のストレスを削る
非同期化すると、待ち時間が目立ちます。だからローディングは要る。hx-indicatorでスピナー要素を指定すると、リクエスト中だけ表示できる。ユーザーの体感が一段よくなるやつです。サイト運営の離脱率にも効きやすい。
環境構築: CDNで始めて、案件になったら依存管理へ
導入は簡単にしたい。まずはCDNで始めるのが早いです。例えばjsdelivrのようなCDNで配布されているビルドを読み込むだけで動きます。実例として、htmx.org@2.0.8をCDNから読み込む形が紹介されている記事もあります。
CDNで読み込む
<script src="https://cdn.jsdelivr.net/npm/htmx.org@2.0.8/dist/htmx.min.js"></script>npmで管理してビルドに乗せる
プロダクションでCDNを避けたい現場も多い。そういう時はnpmで入れて、Viteなどのビルドに乗せればOKです。CDNに依存しない構成にしておくと、CSPや運用ポリシーにも合わせやすい。
npm i htmx.org
1系から2系へ移行する時の逃げ道
既存案件が1系で、でも新規部分だけ2系の思想で触りたい。そういう場面では、1系互換の拡張が用意されています。htmx-1-compat拡張は「1.xから2へのアップグレードをほぼシームレスにする」目的のものとして公開されています。
やり方: 実務で使える小さめレシピ集
理屈より、使える形が欲しい。ここからは現場の匂いがするやつです。
検索フォームをインクリメンタルにする
検索ボックスに入力したら結果だけ更新。いわゆるライブ検索。hx-triggerを使えばいけます。入力のたびに送るとサーバが泣くので、delayを挟む癖を付けたいところ。
<input
type="search"
name="q"
placeholder="検索"
hx-get="/search"
hx-trigger="keyup changed delay:300ms"
hx-target="#results"
hx-swap="innerHTML">
<div id="results"></div>
無限スクロール風に追加読み込み
全部を一気に描画しない。ユーザーが欲しい分だけ読み込む。これは体験的にもパフォーマンス的にも効きます。hx-swapでappend寄せ、次ページURLをサーバで返す。雑に強い。
<div id="feed">
<!-- 初期表示 -->
</div>
<button
hx-get="/feed?page=2"
hx-target="#feed"
hx-swap="beforeend">
もっと読む
</button>
モーダルの中身だけサーバから取る
モーダルはUIの鬼門です。状態を持つし、アクセシビリティも難しい。htmxでやるなら「外枠は静的」「中身はサーバのHTML」を返すのが扱いやすい。更新対象も限定できる。
<button
hx-get="/user/42/modal"
hx-target="#modalBody"
hx-swap="innerHTML">
詳細を見る
</button>
<div id="modal" hidden>
<div id="modalBody"></div>
</div>
メリット: ここが刺さると手放せない
1. HTML主導なので、チームで理解しやすい
JSの抽象度を上げすぎると、知っている人しか触れない構造になります。htmxはHTMLに書いてある。読めば分かる。レビューもしやすい。保守が回りやすい。
2. ビルド無しでも始められる
学習コストを抑えたい時、これが効く。CDNで始めて、必要ならビルドへ。段階が踏めるのがいい。
3. SEOと相性が良い設計になりやすい
サーバがHTMLを返す前提なので、コンテンツが見える。検索エンジンにも人間にも優しくなりやすい。もちろん実装次第ですが、少なくとも「JSが動かないと何もない」地獄は避けやすいです。
4. ちょい足しUIが速い
問い合わせフォームの確認表示、管理画面の並び替え、検索の自動更新、コメント投稿。こういう「少しだけ動けばいい」が早い。ここが現場で一番価値が出る。
デメリット: ここを知らないと事故る
1. サーバ側の設計が雑だと破綻する
htmxはサーバがHTMLを返すので、テンプレートの分割や部分レンダリングの設計が要ります。APIだけ作って終わり、みたいなチームだと考え方が変わる。サーバもフロントも一緒に設計する必要が出てきます。
2. 複雑な状態管理は向かない場面がある
超複雑なウィザード、オフライン同期、ローカルで完結するリッチ編集。こういうのはSPAの方が楽なこともある。全部をhtmxでやると、逆に泥沼になる可能性もある。
3. DOM差し替え前提なので、既存JSとの整合が課題になる
差し替えた要素に、既存のJSがイベントを付けている場合。差し替えた瞬間にイベントが消える。あるあるです。委譲で逃げるか、htmxのイベントに乗るか、整理が必要。放置するとバグが出るタイプ。
4. キャッシュや履歴の設計をサボると体験が荒れる
部分更新は便利ですが、ブラウザ履歴や戻るボタンの体験をどうするかを考えないと、ユーザーが迷子になります。hx-boostやpush-url周辺の設計を、最低限押さえたい。
なぜ止める必要があるのか: htmxをやめた方がいい場面もある
この項目、htmxの記事で書くのはちょっと面白いですよね。でも現場のためには必要。何でもかんでも導入して「うちのサイト、全部htmxで行けるはず」という謎の宗教になると、だいたい燃えます。
止めた方がいいサイン1: UIがほぼアプリで、状態が複雑すぎる
スプレッドシート級の編集画面、常時同期するコラボ編集、重いクライアント側計算。こういうのは、サーバレンダ中心の差し替えでは苦しいことが多い。最初からSPAや専用設計の方が良い。
止めた方がいいサイン2: バックエンドがHTMLを返すのを極端に嫌がる
APIしか返さない、JSONが正義、テンプレートは絶対に書かない。そういう組織文化だと、htmxの価値が出にくい。戦うコストが増えるだけになる。最初からその文化に合う選択をした方が、チームの幸せに近い。
止めた方がいいサイン3: 既に巨大なSPAが完成している
完成しているものを無理に混ぜると、二重管理になります。htmxは部分導入が出来るけど、境界の設計が要る。勢いだけで混ぜると、デバッグ地獄です。
セキュリティと運用: ここを押さえると安心度が上がる
CSRF対策はサーバの流儀でやる
htmxはPOSTもします。つまりCSRFの話が出る。多くのフレームワークはCSRFトークンを持っているので、その仕組みに乗せればいい。メタタグにトークンを入れて、リクエストヘッダに載せる。フォームにhiddenで入れる。現場の標準に合わせて下さい。
部分HTMLの返し方を決める
毎回フルHTMLを返すのか、部分だけ返すのか。テンプレートをどう分割するのか。ここは運用設計です。おすすめは「同じテンプレートを部分でもページでも使えるようにする」寄せ方。二重管理を減らすのが勝ち筋。
ログと監視も忘れない
htmx導入後に増えるのは「細かいリクエスト」です。サーバログが増える。監視も変わる。障害時に追いにくくならないよう、エンドポイント設計とログの粒度は意識しておきたい。
実務での設計Tips: 失敗しがちな所を先に潰す
差し替える範囲を小さくする
でかい領域を差し替えるほど、既存JSやCSSとの衝突が増えます。まずは小さく。検索結果だけ。通知だけ。フォーム結果だけ。そこで勝ってから広げる。これが安全です。
レスポンスはHTMLを返す。JSONを返したくなったら一呼吸
JSONを返して、クライアントで描画する。そうすると結局SPA寄りになります。もちろんそれでも良いけど、htmxの旨味は薄くなる。HTMLを返す方が早いこと、わりと多いです。
CSSとテンプレートの責務を分ける
部分HTMLが増えると、CSSのスコープが荒れやすい。BEMでもいいし、@scopeでもいい。とにかく、部分の責務を小さく保つ。htmx導入より、こっちが大事な場面もあります。
読者に役立つ関連トピック: htmxと一緒に覚えると強い
1. サーバサイドテンプレート分割
Railsならpartial、Djangoならinclude、Laravelならcomponents、Expressならejsのinclude。何でもいい。部分HTMLを気持ちよく返せる構造にするだけで、htmxは輝きます。
2. HTTPとブラウザの基本
GETとPOSTの違い、キャッシュ、Cookie、SameSite、CSP。htmxはブラウザの上で動くので、結局ここに戻ってきます。基礎が強い人ほど、htmxの導入が上手い。
3. 既存JSの整理: イベント委譲と再初期化
差し替えで消えるイベントは委譲で逃げる。差し替え後に再初期化が必要なら、フックポイントを作る。これだけで事故が減ります。
4. 1系から2系の混在対策
既存サイトに少しずつ入れるなら、互換拡張を検討する価値があります。いきなり全部置き換えない。移行は段階が踏める方が強い。
おすすめの関連作品: htmxが好きなら、こういう方向も気になるはず
HTML主導のUI設計
Web Componentsや、progressive enhancementの文脈。あるいはサーバサイドレンダの再評価。htmxはその流れの中にいます。流行りではなく、振り子の反動としての必然。そういう匂いがする。
軽量フロントの仲間
Alpine.jsのように、最小限のJSでUIを作る思想も近い。全部を統一しなくてもいいけど、チームの哲学として「軽く作って、必要なら増やす」を持っておくと、選択がぶれにくいです。
出典メモ
・htmxの基本機能や属性の概念は公式ドキュメントと属性リファレンスに基づく: hx-get/hx-post/hx-target/hx-swap/hx-boost/hx-triggerなど。
・htmx 2系と1系互換については、公式拡張 htmx-1-compat の説明を参照。
・2.0.8がlatestである点はunpkgのパッケージ一覧表示を参照。
