SPA との使い分け

この章のねらい

Hotwire を学ぶと、「では React や Vue のような SPA は要らないのか」と考えたくなります。しかし、これは「どちらが優れているか」の問題ではありません。向き不向きがあり、選択肢の問題です。

この章では、Hotwire と SPA を対立ではなく選択肢として比較し、どんなときにどちらが向くかを整理します。

両者を分ける主な軸は、次のとおりです。

この軸で見ると、両者は「描画と状態を、サーバー寄りに置くか、クライアント寄りに置くか」で分かれていると分かります。

ただし、これは高レベルの単純化です。近年は SPA 側にも、サーバーで描画するメタフレームワーク（Next.js など）があり、「サーバー描画かクライアント描画か」の線は実際にはぼやけています。ここでは大づかみの違いとして捉え、細部はそれぞれの技術で確認してください。

Hotwire と SPA の比較軸。描画・状態・通信・JavaScript 量の 4 軸上で両者の位置を対比し、SSR メタフレームワークで境界がぼやけることも示すスペクトラム図

Hotwire が向くのは、次のような場面です。

多くの業務アプリは、この範囲に収まります。Relay も、Hotwire で無理なく作れました。

一方、SPA が向くのは、次のような場面です。

「サーバー往復を挟まずに、クライアントだけで完結させたい操作」が多いほど、SPA が向きます。

「全部 Hotwire か、全部 SPA か」だけが選択肢ではありません。混在もできます。

たとえば、アプリの大部分は Hotwire で作り、特に複雑な 1 つのウィジェット（高機能なエディタなど）だけ、React のコンポーネントを島のように埋め込む、という形です。Stimulus から、その島を初期化・破棄します（第22章の外部ライブラリ連携と同じ考え方です）。

「複雑なところだけクライアントに寄せ、それ以外はサーバー中心のまま」という混在は、現実的な選択肢です。最初から全部を SPA にしなくても、必要な箇所だけ強い道具を使えます。

判断の分かれ目の一つが、API です。

Hotwire は HTML を返すので、Web のためだけなら、JSON API は要りません。しかし、モバイルアプリ（ネイティブで作り込む場合）や、外部サービス連携で、どうせ JSON API が要るなら、話が変わります。

ただし、Hotwire Native（第9部）を使えば、モバイルのためだけに JSON API を用意しなくても済むことがあります。Web の HTML をそのまま使うからです。「本当に JSON API が必要か、それとも HTML で足りるか」を見極めると、不要な API 設計を避けられます。

技術選定は、チームの事情も含めて決めます。

Rails に強く、JavaScript の専任が少ないチームなら、Hotwire は学習・保守のコストを抑えられます。サーバー側の知識がそのまま活きるからです。逆に、フロントエンドに強いチームで、すでに SPA の資産があるなら、SPA を選ぶ合理性もあります。

「技術的に何ができるか」だけでなく、「このチームが、これを何年も保守できるか」まで含めて判断します。これが、第10部の視点「使い続けて保守できるか」です。

CRUD 中心か、クライアント状態、オフライン、チーム、API 要否の問いから、Hotwire 向きか SPA/混在向きかを導く図。

最後に、判断の目安をまとめます。次に多く当てはまるほど、Hotwire が向きます。

逆に、クライアント状態が大きい・オフラインが要る・すでに API 中心、に多く当てはまるなら、SPA や混在を検討します。Hotwire は万能ではありませんが、多くの業務アプリにとって、十分で、保守しやすい選択肢です。

第37章では、Hotwire と SPA を選択肢として比較しました。次の第38章では、Hotwire の現在地と今後を見て、本書を締めます。