HotwireとReactの違いを理解する

Reactとの比較を通して、Hotwireの特徴を考えます。

HotwireとReactの違い

先にまとめると、HotwireとReactの違いは以下の通りです。

HotwireもReactも複雑なUI/UXが作れます
画面に表示されている内容をJavaScriptで操作するという意味ではHotwireもReactは全く同じです。JavaScript/HTML/CSSをどのように書くかという違いしかありません。原理的にHotwireとReactで実現できるUI/UXに差は生まれません。
画面数が多いシステムはHotwireの方が適しています
Hotwireの方がReactよりも大幅に工数・コード量はが少なくなります。SaaSプロダクトのページ数が500以上というのは一般的ですが、これをすべてReactで作るのは現実的にかなり難しいです。将来的に大きくなる可能性があるアプリは、Hotwireが有利です。
複雑なシステムはHotwireの方が適しています
アプリが成長するとビジネスロジックが複雑化します。また認証・認可の要求が高度化していきます。サーバ側のドメインオブジェクトに直接アクセスできると、複雑なロジックの記述が簡素になります。HotwireはサーバでHTMLをレンダリングしますので、ロジックが複雑なシステムならHotwireの方が適しています。

論より証拠です。実際にHotwireで作られているアプリを確認してください。優れたUI/UXが実現できるのは疑いの余地がありません。

下のビデオは37signals社のFizzyですが、無料で試すこともできます。ソースコードもGitHubで公開されています。

ReactはJSONシリアライザ、OpenAPIドキュメント、クライアントサイドルータ、APIをfetchする処理、認証やセッション管理、ステート管理等が必要になります。これらはHotwireでは不要です。React等のモダンフロントエンドに限って必要なものです。
負担が大きいのはフロントエンドエンジニアだけではありません。バックエンドエンジニアもJSONシリアライザおよびOpenAPIドキュメントを作成しなければなりませんが、これもHotwireであれば全く不要です。
結果としてHotwireの方が少ない工数で高速に開発ができます。またコード量が少ないので保守性が高くなり、AIを使うのであれば、消費トークン数も大幅に少なくなります。

UIに複雑なデータを表現するケースはかなり多くあります。

Reactの場合、一つのページを表示するのにREST APIエンドポイントを５つ程度叩くことは珍しくありません。各々の読み込み状態やエラーを管理したり、情報をステートとして保持したりする必要があり、コードが複雑化します。また仕様が追加されればAPIエンドポイントを追加・修正する必要があります。
ERBの場合はテンプレートの名から直接生きたドメインオブジェクトにアクセスします。ログインしているユーザの情報はテンプレートからcurrent_userを呼ぶだけでアクセスできますし、関連データも@blog.comment.authorなどとするだけで取得できます。APIエンドポイントを追加・修正する必要はなく、メソッドを呼び出すだけです。

アプリが高度化して画面が複雑化しても、Hotwireはドメインロジックへのアクセスが複雑化しません。

例えばログインしているユーザの権限に応じて投稿の「削除ボタン」を表示するロジックを考えます。

Reactの場合、複数の戦略が考えられます。
- /me等のエンドポイントでログインしているユーザのロールを返す方法があります。ユーザがadminもしくは投稿の作者であれば、「削除ボタン」を表示するロジックをフロントエンドに書き、「削除ボタン」の表示・非表示を切り替える方法です。しかしこれはポリシーをフロントに記述することになるので、認可ロジックが複雑になると管理し切れなくなります。
- /post/:idもしくはその他のAPIエンドポイントの中でcanDeletePost: [boolean]を返す方法もあります。ポリシーの判定をサーバ側で行い、結果をフロントエンドに返す方法です。canDeletePostの値に応じて「削除ボタン」の表示・非表示を切り替えます。認可ロジックをサーバに集約できるので管理しやすくなります。
Hotwireの場合、 ERBの中でif policy(@post).destroy?をチェックします(Pundit gemの場合)。ERBから直接認可ヘルパーメソッドにアクセスできますので、APIエンドポイントを修正することなく、認可ロジックをサーバに集約させたままにできます。

複雑な権限をUIに反映させる際も、Hotwireであれば簡単に管理できます。ポリシーをフロントエンドに記述する必要もなく、エンドポイントの追加・修正も不要です。