## なぜ私がAlpine.jsにたどり着き、HTMXから距離を置いたのか {#sec-a4901ce975c0}

こんにちは。本日は、バックエンド中心のDjango開発者として、最近のフロントエンドエコシステムで「[[JavaScript]]をあまり書かない」というトレンドを牽引する二つの主役、**[[Alpine.js]]**と**[[HTMX]]**についてお話ししたいと思います。

私のようにDjangoやPythonに慣れ親しんだ者にとって、これらのツールは非常にありがたい存在です。複雑なReactやVueの設定なしに、それなりのモダンなウェブサイトを構築できるからです。しかし、この二つのツールは使用目的と特性が大きく異なります。HTMXはサーバーとの通信に特化しており、Alpine.jsはブラウザ内部のUI操作に特化しています。

結論から申し上げると、私は**Alpine.js**の大ファンとなり、**HTMX**とは少し距離を置くようになりました。その理由を率直に共有させていただきます。

![htmxとAlpine.jsの比較画像](/media/whitedec/blog_img/f0fd0eabe37b4dfdba84c4413b0ed893.webp)

---

## 1. 事前知識: [[HTM]]X vs [[Alpine.js]] 一目でわかる比較 {#sec-588a3f69cb07}

本題に入る前に、これら二つの概念が初めての方のために、簡単な比較表をまとめました。

| 区分 | HTMX | Alpine.js |
| :--- | :--- | :--- |
| **主な目的** | **サーバー通信** (AJAXリクエスト後のHTML置換) | **クライアント状態管理** (UIインタラクション) |
| **哲学** | HTMLの拡張 (サーバー中心) | Vue/Reactの軽量化 (ブラウザ中心) |
| **データ形式** | **HTMLスニペット** | **JSONデータ** |
| **主な強み** | 無限スクロール、リアルタイム検索 (SSR方式) | モーダル、ドロップダウン、タブ切り替え (CSR方式) |



---

## 2. 私がHTMXを次第に避けるようになった4つの理由 {#sec-cbf50b3543fc}

HTMXは一見すると非常に便利です。しかし、実際にプロジェクトに深く適用してみると、私の開発スタイルと衝突する点が出てきました。

### ① 「わざわざHTMLスニペットをサーバーで生成する必要があるのか？」 (保守のジレンマ) {#sec-ccc17c7c9816}
HTMXを使用するには、サーバー(Django)がJSONではなく**HTMLスニペット**を返す必要があります。これが私の性には合いませんでした。
* **私の視点:** 「サーバーはデータだけをきれいに渡し、レンダリングはクライアントが行うのが役割分担として明確ではないか？」
* **HTMXの立場:** 「JSONを受け取って再度レンダリングするのは無駄だ。サーバーが最終結果物を提供するのが真実の源泉(SSOT)だ。」

Djangoテンプレート内で`if request.htmx:`のような分岐処理を入れると、ビュー(View)ロジックが断片化され、ごちゃごちゃするという印象を拭えませんでした。

### ② AJAXロジックは、もう十分に簡単ではないか？ {#sec-3d93df5c1f47}
HTMXの`hx-get`、`hx-target`は素晴らしい「シンタックスシュガー」です。しかし、すでにVanilla JSや自分なりのユーティリティ関数でAJAXを実装した経験がある人にとっては、もはや必須ではありません。
最近のブラウザの**fetch API**は本当に強力です。Alpine.jsの`x-init`内でfetchを一行書くだけで、十分に宣言的でクリーンなコードが書けるのに、わざわざ別のライブラリのルールに従う必要性を感じなくなりました。

### ③ 致命的な「Locality of Behavior (LoB)」の断絶 {#sec-2cd75954bdb6}
私はAlpine.jsが本当に好きです。コードが何をするのか**その場で一目瞭然だから**です。しかし、HTMXは異なります。
* **Alpine.js:** 振る舞い(Behavior)がHTML内にあり、結果もブラウザメモリ内で即座に発生します。
* **HTMX:** 振る舞いはHTMLに定義されていますが、**結果物(HTMLスニペット)を確認するには、再度サーバーコード(`views.py`)を探る必要があります。**

この過程でコンテキストが途切れるのが非常に非効率だと感じました。コードを読んでいる途中で何度もバックエンドファイルを開かなければならない煩わしさ、それがhtmxを避けるようになった決定的な理由の一つです。

### ④ 微細なレイテンシ(Latency)の不快感 {#sec-c2deaaea82da}
HTMXは、すべてのインタラクションがネットワークラウンドトリップを前提としています。

サーバーがいくら高速でも、ブラウザ内部で即座に反応するAlpine.jsの速度にはかないません。クリックした際に0.1〜0.2秒ほど感じられるその微細な遅延が、ユーザーエクスペリエンスの観点から私にとってはかなり気になる要素でした。

---

## まとめ：皆さんのご意見はいかがでしょうか？ {#sec-fbc8664e9292}

まとめると、私は**データはAPI(JSON)で流れ、UIはブラウザ内で即座に反応すべきだ**という構造を好みます。そのため、Alpine.jsとDRF(Django REST Framework)の組み合わせが最も気に入っています。

興味深いことに、最近Redditのようなコミュニティを見ると、私とは正反対の意見も多く見られます。[[Alpine.js]]を複雑だと感じ、HTMXや、さらにはjQuery + HTMXの組み合わせに戻る方々も少なくありませんでした。いずれにせよ、最近はHTMXの人気が圧倒的なようです。

もちろん、[[HTMX]]は非常に優れたツールです。単に私の開発スタイルやシステム設計方法に合わなかっただけなのです。**「正解はなく、自分に合った服があるだけ」**という考えに至りました。

皆さんはどう思われますか？HTMXのサーバー中心の哲学に満足していますか、それとも私のようにJSON応答とAlpine.jsの即時反応性をより好みますか？コメントでご意見をお聞かせください！

もしかしたら、私はHTMXの真の力を理解する前に、あまりにも早く距離を置いてしまったのかもしれませんね。