Next.js と比べた時の Remix の使いどころ

自分は以前から Next.js を使って開発していましたが、最近 Remix も使う機会がありました。
その結果、Next.js だけでなく、Remix も（当たり前ですが）十分に有用で、今後のプロダクション採用にも検討し得ると感じました。

ここでは、実際に Remix を使用して良かった点と、Next.js ではなく Remix を選びたい場合について書きたいと思います。

※ パフォーマンスなどについては比較しておらず、主に開発体験がメインの簡単な比較です（Remix による Remix は良いぞ記事もありますが個人的に半信半疑ですw）

Remix の特徴

サーバーサイドの更新処理を View の近くに配置できる

通常、フロントエンドでの入力フォーム実装にはバリデーションが必要です。しかし、ブラウザ上だけのバリデーションでは不十分で、結局サーバーサイドでも同様のバリデーションが必要になることがあります。

Remix では、View（フォーム）から送信されたデータをサーバーサイドで操作する処理を、 .tsx(.jsx)ファイル内に配置することができます。そのため、更新に伴う処理をクライアントとサーバーで共有し、ブラウザ上でも迅速にバリデーション結果を表示しながら、サーバー側でも確認することができます。

Next.js でも API Routes を使用すれば同様のことが可能ですが、位置的に View から離れてしまうため、この点に関して Remix の書き味は良いなと感じました。

Nested Routes (Nested Layouts) に対応している

Remix では、ルーティングの親子関係からレイアウトを制御できます。たとえば、 /dashboard/settings というルートがある場合、dashboard は子である settingsのレイアウトを決める責任を持ちます。

そのため、 dashboard/ 配下のレイアウトを共通化して定義でき、子は自分自身の表示だけに専念することができます

Next.js でも、getLayout という書き方が存在し、今ではApp Router (app Directories)という仕組みも作られ始めています。
しかし、

• 前者はルーティングごとにレイアウトを決定できるだけであり、例えば/dashboard/settingsのレイアウトを個別に定義することはできるが、そこに親である /dashboard のレイアウトは絡まない
• 後者はまだベータ版である

という懸念が残ります。一方で、Remix は現時点でも安心して利用できるのが嬉しいです。

まとめ

個人的に Remix を積極採用したいケースは、以下のような場合です。

• サーバーサイドの更新処理を簡単に実装したい場合
• Nested Routes を安心して使いたい場合

2点目については、Next.js もいずれ追いついてくると思いますが、1点目に関しては Remix の特徴として今後も活きていくような気がします。（逆に、この部分が Remix の「クセがすごい」ところでもあるかもしれません・・w）

例えば、更新処理を主とする管理画面のようなアプリケーションを作成する場合には、個人的には Remix を積極的に採用していきたいと考えています。

※ちなみに Remix は SSR 前提のため、それが難しい場合には最初から候補から外れます。

以上です。
他にもこんな時に Remix 向いてるよ or 向いてないよという意見があればコメントいただけると幸いです。