Please just try HTMX

Japanese Translation:

要約

HTMX は、HTML の任意の要素に宣言的属性（例：

hx-post

、

hx-swap

）を追加することで、開発者がインタラクティブなウェブページを作成できる小さなライブラリです（サイズは約 14 KB（gzipped））。これらの属性は HTTP リクエストをトリガーし、返された生 HTML を直接ページに差し替えるため、JavaScript コードや複雑なビルドツールが不要になります。簡単な例としては、クリック後にサーバー側でレンダリングされたコンテンツに置き換わるボタンがあります。

実際に Contexte は React を中心としたスタックから Django テンプレート＋HTMX に移行し、全体のコード量を 67 %（21,500 行 → 7,200 行）削減し、JavaScript の依存パッケージ数を 96 %（255 パッケージ → 9 パッケージ）に減らし、ビルド時間を 88 %（40 秒 → 5 秒）短縮、ページロード時間を約 50‑60 %（2‑6 秒 → 1‑2 秒）削減しました。ページ読み込み速度は約半分に改善されました。HTMX はライブ検索、「もっと読む」ページネーション、フォーム送信などの一般的なパターンも自然にサポートします。

HTMX は特にダッシュボード、管理画面、e‑commerce サイト、ブログ、およびフォームやリストを利用する SaaS アプリケーションに適しています。ただし、リアルタイム協働編集（例：Google Docs）、重いクライアント側計算（ビデオエディタ、CAD ツール）、オフラインファーストのアプリケーション、または単純なフォーム検証を超える本当に複雑な UI ステートには推奨されません。

著者は開発者に対し、週末に小さなサイドプロジェクトで HTMX を試してみることを勧めています。失敗した場合のコストは最小限ですが、多くの人がそのパワーに驚くでしょう。詳細については公式ドキュメント（

htmx.org

）と無料書籍「Hypermedia‑Driven Apps」（

hypermedia.systems

）をご覧ください。

私の「冷静だが意見はっきりした」訴え ― もうあなたを苦しめるのはやめてほしい

まず言っておくと、私はあなたに「クソバカ」と毎文呼び続けるつもりはありません。すでにその手法は確立されていて、今では一種のジャンルになっています。正直なところ、HTMX が自分の主張を伝えるために私が叫ぶ必要は全くないのです。

**「汚い言葉を使ったウェブ宣言」**は楽しいものです — それらを読んできました。でも現実を見てください。「HTML を使え！」や「React をクソ使え！」と大声で叫んでも、誰もスタックを変えることはありません。人々はうなずいて笑い、そしてまた自分の生JSやwebpack設定に戻ってしまいます¹。

そこで私は別のアプローチを試みます。まだ汚語を使います（私は「クソ聖人」ではありません）が、あなた自身の sanity と happiness のために何かを示します：少なくとも HTMX を 一度は試してみてください。

誤った選択

今、叫び声を上げる者たちはあなたに二つの選択肢を提示しています：

Option A: 「HTML だけで十分！」
彼らが間違っているわけではありません。HTML は驚くほど強力です。フォームは動きます。リンクも動きます。
```
<dialog>
```
要素も今や存在します。ウェブはこの技術で構築され、Tim Berners‑Lee が髪を生やしていた頃から進化し続けています。ちょっとした CSS だけでも 母親が怒るほど 効果があります。
Option B: React（あるいは Vue, Svelte, Angular 等）
そして突然、次のようなものが待っています：
- ```
package.json
```
  に 847 個の依存関係
- ビルドステップが 45 秒かかる（CI が寛大なら）
- State‑management を巡る議論で PR が汚染される
- Junior dev が
```
useEffect
```
  が二度実行される理由に狂う
- モデム56 k でも泣くようなバンドルサイズ

何のため？タスク管理リストか、問い合わせフォームか、DB から数値を表示するダッシュボード？

これが誤った選択です：生HTML の限界と JavaScript‑フレームワークの地獄。第三の選択肢があります。お願いだから 試してみてください。

HTMX：中間道路

もし私がこう言ったらどうでしょう：

どんな HTML 要素でも HTTP リクエストを送れます
サーバは JSON ではなく実際の HTML を返します
その HTML がページ上の任意の場所に差し替えられます
JavaScript は一切書きません
ライブラリ全体は gzipped で約 14 KB

それが HTMX です。これがすべてです。

<button hx-post="/clicked" hx-swap="outerHTML">
  Click me
</button>

クリックすると HTMX は

/clicked

に POST を送り、サーバから返ってくる HTML がボタンを置き換えます。

fetch()

も

setState()

も

npm install

もクソ webpack 設定も不要です。

サーバは単に HTML を返すだけです ― まるで 2004 年のようですが、ユーザーは高速インターネットを持ち、サーバはそれを処理できます。ウェブ全体が設計された ハイパーメディア アーキテクチャを現代的な便宜と共に再実装したものです。

信じてもらえない？クリックしてみて

このページ自体が HTMX を使っています。以下のデモは実際に動作します：

Demo 1: ボタンをクリック – POST リクエストを送り、レスポンスで置き換えます。
Demo 2: さらに読み込む – このボタンが追加コンテンツを取得し、下部へ追加します。
Demo 3: ライブ検索 – タイプすると結果が即時に更新されます（デバウンス付き）。

これが HTMX です。私は JavaScript を書いてそれらを動かしたわけではありません。HTML 属性だけを書きました。「サーバー」（このデモはクライアント側でモックしていますが、HTMX コード自体は実際のもの）は HTML フラグメントを返し、HTMX がそれを差し替えます。挙動はマークアップにそのまま書かれているので、コンポーネントファイルや state‑management のコードを探す必要がありません。HTMX ではこれを「ローカリティ・オブ・ビヘイビア」と呼びます。これを手に入れれば、他の場所でもそれを見逃すことはありません。

数字で見る

逸話は楽しいですが、データがもっと説得力があります。

ある企業「Contexte」は React から Django テンプレート＋HTMX に移行しました。結果は次の通りです：

指標	Before	After
コード量	21,500 → 7,200 行	67 % 減少
JS 依存パッケージ	255 → 9 パッケージ	96 % 削減
ビルド時間	40 s → 5 s	88 % 速化
ページ読み込み	2–6 s → 1–2 s	50‑60 % 速化

コードベースの三分の二を削除し、アプリは向上しました。すべての開発者が「フルスタック」になり、別々に専門化するフロントエンドがなくなったのです。

コンテンツ中心のアプリなので結果は変わるかもしれませんが、これらの改善点の半分でも週末を投資すれば十分価値があります。

疑い深い人へ

「複雑なクライアント側状態管理は？」
あなたが実際に複雑な状態を持つわけではないでしょう。フォーム、リスト、他の要素をクリックしたときに表示されるものなど — HTMX がすべて処理します。Google Docs のような高度なリアルタイム編集なら別です。
「React エコシステムがある！」
そのエコシステムこそ、
```
node_modules
```
を 2 GB にし、コンポーネントをスタイルする 14 通りの方法を提供し、それぞれにトレードオフがある理由です。「どの state‑management ライブラリを使うか」という議論も未だ続いています。HTMX のエコシステムは「あなたの好きなサーバー側言語」だけです。それだけ。
「SPAs は速く感じる！」
ユーザーが 2 MB の JavaScript をダウンロードし、解析・実行し、ハイドレーションし、データ取得し、レンダリングするときは確かに速いと感じます。HTMX ページは最初の読み込みでアプリケーションランタイムを起動しないため高速です。その後のリクエストも変更した部分だけ差し替えるので速くなります。
「特定の React 機能が必要！」
必要かもしれません。React が答えではなく、使うときにコストが大きいという事実は否定できません。ほとんどのチームはフレームワークを選びすぎて失敗します。HTMX はシンプルさへの投資であり、長期的にはシンプルさが勝るケースが多いです。

HTMX を使わない方がよいケース

私は熱狂者ではありません。HTMX が万能というわけではありません：

リアルタイム共同編集（Google Docs, Figma など）
クライアント側で大量計算を行う（動画編集、CAD ツールなど）
オフラインファーストのアプリケーション（ただし他手段と組み合わせることは可能です）
真に複雑な UI 状態（「フォームがバリデートされている」ではなく、本当に intricately 変化する状態）

正直に自問してください：それがあなたの作りたいものですか？それとも、単なるダッシュボード、管理パネル、e‑commerce サイト、ブログ、または「フォーム・テーブル・リストだけ」の SaaS アプリを構築していますか？そのような場合、HTMX は驚くほど有効です。

まず試してみて

React を試したことがある。Vue も試した。Angular で後悔した経験もある。
HTMX を一度だけ試す。週末を1回使って、社内ツールや面倒なプロジェクトに挑戦してみてください。

<script>

タグを1つ追加し、

hx-get

属性を書くだけで何が起こるか見ましょう。

嫌いなら週末は無駄です。しかし、きっと「どうしてウェブ開発はこんなにクソ複雑だと思っていたのか」と思うようになるでしょう。

さらに学びたい方へ

htmx.org — 公式サイトとドキュメント
hypermedia.systems — ハイパーメディア駆動アプリの無料書籍

¹ 正直に言うと、これは文字通り真実ではありません。bettermotherfuckingwebsite.com は「クソ教育的傑作」であり、私自身のサイト構築を変えました。しかしその部分は伏せておきます…