以前の私は、反射的にVue.jsを選んでいました。どのプロジェクトも同じ手順で始まりました。CLIをインストールし、ルーターをセットアップし、ストアを設定し、それらすべてをシングルページアプリケーション(SPA)のシェルで包み込む。リアルタイムのダッシュボードを作っていようが、単純な問い合わせフォームを作っていようが関係ありませんでした。Vueが私のデフォルトであり、それより軽量なものは後退であると思い込んでいたのです。

この習慣はよくあることです。ReactやVueのエコシステムの中で何年も過ごしていると、SPAモデルは避けられないもののように感じ始めます。本当にそれほど多くの仕組みが必要なのか、と問うことをやめてしまうのです。ただ、それを使う。時間が経つにつれ、私はある厄介なことに気づきました。ステータスを切り替えてテーブルを更新するだけでいい管理画面のために、Vuexストアを構築していました。メールアドレスを送信するだけのランディングページのために、fetchのロジックを組み立てていました。複雑さは問題から生じているのではなく、ツールの選択から生じていたのです。

そんな時、HTMXを使い始めました。その変化は予想していたよりも静かなものでしたが、スタックの選び方を変えることになりました。

HTMXが実際に行っていること

オンライン上の議論の多くは、これを誤解しています。人々はこれをVue対React対HTMXという戦いとして捉えがちですが、その比較は本質を完全に見失っています。HTMXはSPAフレームワークではありません。Vueに取って代わろうとしているわけでもありません。それは、ブラウザが標準で提供するもの以上にHTMLができるようにするライブラリなのです。

マウントしてJSONを取得し、それをローカルの状態にパースしてリストを再レンダリングするコンポーネントを書く代わりに、ボタンに属性を追加するだけです。サーバーはデータのペイロードではなく、HTMLの断片を返します。ブラウザはそのコンテンツを適切な場所に差し替えます。あなたは依然としてサーバーサイドでレンダリングされたページを扱っていますが、人々が重厚なJavaScriptフロントエンドに期待するようなインタラクティブ性を得ることができます。

これはダウングレードではありません。異なるモデルなのです。Vueはクライアントサイドのアプリケーションを構築し、ブラウザ内で状態を管理することを求めます。対してHTMXは、状態をサーバーに保持し、HTMLを通信経路上に流すことを求めます。これらは異なる種類の問題を解決するものなので、どちらも衝突することなく同じプロジェクト内で共存できます。

Vueが依然として正しい選択である場合

複雑なインターフェースにはVueが必要です。ドラッグ&ドロップのウィジェット、ネストされたフィルタリング、複数のビュー間でデータを共有するライブチャートを備えたリアルタイムの分析ダッシュボードを構築する場合、リアクティブなフレームワークが必要になります。その状態はブラウザが所有すべきです。ユーザーがチャートをドラッグしたり、フィルタグループを切り替えたりするたびに、サーバーとの往復(round-trip)を発生させたくはないはずです。Vueのコンポーネントモデル、リアクティビティシステム、そしてエコシステムは、まさにそのために構築されています。

高度にインタラクティブな消費者向けアプリケーションについても同様です。デザインツール、共同作業用ホワイトボード、あるいはミュージックシーケンサーを思い浮かべてください。これらはボタンが付いた「ドキュメント」ではありません。ブラウザ内で動作する「アプリケーション」です。そのような作業において、Vueは今でも私の第一選択です。

HTMXが主役となる場面

最も明確な勝利は、プロジェクトの「退屈な部分」に目を向けた時に訪れました。最初に変わったのは管理パネルでした。管理用のバックエンドには通常、レコードのテーブル、いくつかの操作ボタン、ページネーション付きのフィルタ、そして1つか2つのフォームが必要です。そのどれもに仮想DOMは必要ありません。必要なのは、迅速な部分更新です。

HTMXを使えば、削除ボタンは hx-deletehx-target 属性を持つタグになります。それをクリックすると、ブラウザがリクエストを送信し、サーバーが更新されたテーブルの行を返します