htmx は単なる別の JavaScript フレームワークなのか？

htmx について初めて耳にする人々からよくある批判の一つに、次のようなものがあります。

あなたは現代のフロントエンドフレームワークの複雑さを嘆いていますが、あなたの解決策は単なる別の複雑なフロントエンドフレームワークです。

これは素晴らしい反論です！これは、プロジェクトに導入するあらゆるサードパーティ (3P) コードについて問うべき適切な質問です。3Pコードを自分で書くわけではありませんが、プロジェクトに含めることで、それを理解し、アップグレードする場合はその理解を更新することにコミットすることになります。これは大きなコミットメントです。

この批判を構成要素に分解し、htmxが解決すると主張する害悪に、どれほど関わっているかを正確に判断しましょう。

#ライブラリとフレームワークの違い

htmxの擁護者の中には、「htmxはフレームワークではなく、ライブラリだ」と主張する人がいます。これはおそらく正しくありません。

「フレームワーク」は口語的な用語であり、サードパーティのコードが「ライブラリ」から「フレームワーク」に進化するポイントについて明確なルールはありませんが、それでも定義を試みるべきです。この文脈では

• ライブラリ - APIがアプリケーションの残りの部分に大きな影響を与えない3Pコード
• フレームワーク - APIがアプリケーション全体の構造を決定する3Pコード

メタファーがお好みなら、ライブラリは機械に追加する歯車であり、フレームワークは歯車をカスタマイズすることで制御する、あらかじめ構築された機械です。

この区別は曖昧ではありますが、サードパーティのコードがどれほど簡単に置き換えられるかを説明する上で重要です。たとえば、CSV解析ライブラリを使用するJavaScriptサービスは、あまり手間をかけずに別のCSV解析ライブラリに交換できる可能性があります。しかし、NextJSフレームワークを使用するJavaScriptサービスは、コードの大部分がNextJSの構造と対話することを前提に書かれているため、おそらくその耐用年数全体を通してNextJSに依存することになります。

したがって、サービスがフレームワークの上に構築されている場合、そのサービスの耐用年数はそのフレームワークの耐用年数に結び付けられます。そのフレームワークが放棄されたり、軽蔑されたり、そうでなければ作業したくない場合は、プロジェクトの修正の難易度が徐々に増し、最終的には修正を諦め、最終的に完全に廃止することになります。

人々が「htmxは単なる別のJavaScriptフレームワークなのか？」と尋ねるときに心配しているのは、まさにそのことです。彼らは、過去の多くのWeb開発フレームワークのように、すぐに時代遅れになるシステムにコミットしたくないのです。

では、htmxはフレームワークなのでしょうか？そして、流星のような衰退の後に、メンテナンスできないWebサイトの痕跡を残して、すぐに時代遅れになるのでしょうか？

#htmxは（通常）フレームワークである

この質問に関するコミュニティの継続的な議論については申し訳ありませんが、少なくとも大多数のユースケースでは、htmxは非常に明確なフレームワークだと思います。ただし、それは使い方によって異なります。

プロジェクトでhtmxを使用する場所では、HTMLにhtmx属性 (例: hx-post、hx-target) を含め、htmx形式のデータ (特定の要求ヘッダー付き) で呼び出されるエンドポイントを作成し、htmxが期待する方法 (hx-*コントロール付きのHTML) でフォーマットされたデータをそれらのエンドポイントから返します。これらの属性、ヘッダー、およびエンドポイントはすべて相互に作用して、要素がネットワークリクエストを介してDOMに出入りするシステムを作成します。

Webサイトのネットワークリクエストの多くを処理するためにhtmxを使用する場合、アプリケーションへのhtmxの組み込みは、フロントエンドのマークアップを構造化する方法から、エンドポイントが作成するデータベースクエリまで、プロジェクトの構造に大きな影響を与えます。それはフレームワークのような動作であり、そのシナリオでは、htmxを簡単に置き換えることはできません。

Webページのほんの数か所に動的な機能を追加するために、ライブラリのようにhtmxを使用することはできます。しかし、Reactもこのようにライブラリのように記述することができ、Reactがフレームワークではないと主張する人はいません。多くの人がアプリケーションでhtmxを使用する場合、ハイパーメディアアプリケーションを構築するためのフレームワークとして、htmxの要求に従う方法でそれを行っていると言えます。

そのようにすべきです！htmxで構築することは、その長所を生かせばはるかにうまく機能します。どうしてもというのであれば、JSON形式のフォームボディを送信できます。本当に主張する場合。しかし、そうすべきではありません！application/x-www-form-urlencodedボディを使用して、それを受け入れるエンドポイントを記述する方が簡単です。どうしてもというのであれば、複数の異なるクライアントで再利用されるエンドポイントを記述できます。本当に主張する場合。しかし、そうすべきではありません！データをハイパーメディアAPIを別々のURLに分割する方が簡単です。はい、htmxはライブラリとして使用できますが、フレームワークとして使用することも許可してください。

しかし、それはhtmxが単なる別のJavaScriptフレームワークであることを意味するわけではありません。なぜなら、htmxには他のフレームワークにはない大きな利点があるからです。それはHTMLです。

#htmxはHTMLを書くためのもの

htmxをフレームワークとして使用しているとしましょう。それはJavaScriptフレームワークなのでしょうか？明らかな意味では、はい。htmxは約4k行のJSで実装されています。しかし、別の、はるかに重要な意味では、そうではありません。React、Svelte、Solidなどは、フレームワークがHTMLに変換するJS(X)を書く必要があります。htmxは単にHTMLを書くだけです。これにより、時間の経過とともに他のフレームワークを放棄する可能性のあるメンテナンスのカテゴリ全体が削除されます。

コードベースは、依存関係をアップグレードまたは変更したいが、使用しているフレームワークがその変更と互換性がない場合に、行き詰まる傾向があります。Javaは最も悪名高い例です。Springのアップグレードが難しすぎるため、Java 8から決して移行しない運用環境にあるJavaの行が数え切れないほどあります。npmパッケージのエコシステムもそれに次ぐものです。htmx「フレームワーク」を使用する場合、この問題は決して発生しません。なぜなら、htmxは依存関係のない、クライアントロードされたJavaScriptファイルであるため、サーバーが依存するビルドプロセスや依存関係チェーンと競合しないことが保証されているからです。

ブラウザーはHTMLをレンダリングするため、htmxを使用するためにコンパイラーやトランスパイラーは必要ありません。多くのhtmxユーザーはAPI応答をJSXでレンダリングすることを喜んでいますが、htmxは従来の テンプレート エンジンと非常によく連携し、任意の言語に移植可能です。DjangoとRailsについては何でも言ってください。2008年には関連性がありましたが、今日も関連性があります。htmxはどちらともシームレスに統合できます。これはhtmx駆動開発の繰り返しテーマです。htmxは、新旧のさまざまな開発ツールとうまく連携します。なぜなら、これらのツールすべてに共通する分母はHTMLであり、htmxはHTMLを書くためのものだからです。

ユーザーにアプリケーションの動作を主にJSではなくHTMLで定義させることには、このエッセイでカバーするには多すぎるほどの利点があるため、JavaScriptフレームワークについて人々が最も嫌う1つの点に絞ります。それは変化の激しさです。Reactアプリケーションを作成した時期によっては、制御されたクラスコンポーネント、またはreactフック、またはこの実験的な<form>拡張を使用してフォームを作成した可能性があります。特に、私のように、クラスコンポーネントでWebフォームを作成する方法を最初に学んだ場合は、これは本当に腹立たしいことです。

しかし、htmxアプリケーションを作成した時期に関係なく、htmxフォームの動作は、常に通常のHTMLフォームとほぼ同じ方法で定義されてきました。つまり、<form>を使用します。htmxがネットワーク機能を追加することで、PUTリクエストを最終的に使用して、応答がどこに行くかを制御できますが、それ以外のすべての点 (検証、入力、ラベル、オートコンプリート) では、デフォルトの<form>要素の動作が適用されます。

最後に、htmxは非常に狭いドメイン (ネットワークリクエストとDOMの置換) でHTMLを拡張するだけなので、記述する「htmx」のほとんどは、単なる昔ながらのHTMLです。複雑な状態管理メカニズムにアクセスできる場合は、カスタムの折りたたみ式divを実装するのが非常に簡単です。そうでない場合は、<details>要素を検索するために十分な時間をかけるかもしれません。ネイティブHTML要素で問題を解決できる場合は、その結果としてコードの寿命が大幅に向上します。これは、Web開発を学ぶ上で、あまり疎外感を感じない方法です。なぜなら、知識の大部分はHTMLが存在する限り関連性が保たれるからです。

この点に関して、htmxはReactよりもJQuery (htmxの前身であるintercooler.jsはJQuery拡張機能でした) に似ていますが、宣言型のHTMLベースのインターフェースを使用することでJQueryを改良しています。JQueryでは<script>タグに移動してAJAXの動作を指定する必要がありましたが、htmxでは単純なhx-post属性のみが必要です。

要するに、htmxはフレームワークとして使用できますが、JavaScriptフレームワークよりもWebのセマンティクスから逸脱することがはるかに少ないフレームワークであり、Webの優れた下位互換性保証のおかげで、ユーザーの追加作業なしに、それらのセマンティクスの改善から恩恵を受けることができます。長く続くWebサイトを構築したい場合、これらの品質により、htmxは多くの同時代のものよりも大幅に優れた選択肢となります。

注: この分析に同意し、エッセイに論理的な欠陥がないことを認め、彼のWebサイトでの公開を許可しているにもかかわらず、カーソンはhtmxがライブラリであると主張し続けています。