Next.jsとRemixを触ってみて感じた違いと共通点 ― Reactベースのフレームワーク、どっちが合う？
Reactをベースとしたフレームワークはここ数年でかなり増えてきましたが、なかでも「Next.js」と「Remix」は特によく話題に上がる存在です。今回は、その両方を実際に軽く触ってみて感じたことを、ざっくりまとめてみたいと思います。
目次
まずは「どちらもReact」
Remixを触ってみて最初に感じたのは、「あ、これもReactだな」という安心感でした。Next.jsと同様に、基本的にはコンポーネントベースで構築していくので、Reactに慣れていればすんなり入っていけます。
たとえばリンクを張るときも、Next.jsでは<Link href=”/about”>と書いていたのが、Remixでは<Link to=”/about”>になるだけです。Linkというコンポーネント自体は共通なので、React Router由来のAPIに馴染みがあれば違和感なく使えます。
Tailwind CSS が最初から効くのも嬉しい
もうひとつ個人的に好印象だったのが、Tailwind CSSの環境が最初から整っていたこと。Remixの公式テンプレート（Remix App Server＋TypeScript構成）でプロジェクトを立ち上げてみたところ、Tailwindのクラスをそのまま書くだけでスタイルが適用されました。
Tailwindに慣れていると、「classNameに書くだけでスタイルがあたる」気軽さがありがたいんですよね。Next.jsでも自分でセットアップすれば同じことはできますが、最初から入っているとそれだけで開発のスピード感が上がる気がします。
SSR・ルーティングの思想は少し違うかも
Next.jsとRemixの違いとしてよく語られるのは、サーバーサイドレンダリング（SSR）やルーティングの設計思想です。
このあたりについても少しだけ調べてみました。
Next.jsではApp Router（または従来のPages Router）によってファイルベースのルーティングが主流で、API RoutesやMiddleware、ISR（Incremental Static Regeneration）なども使えるようでした。Vercelとの相性もよく、商用プロジェクトでの導入実績も多い印象です。
一方、Remixはより「Web標準に寄せた設計」が特徴的のようでした。フォームの送信やuseLoaderDataでのデータ取得など、「クライアントとサーバーの責務をはっきり分けすぎず、まとめて扱う」ような思想を感じます。React Routerとの統合も進んでいて、より柔軟なルーティング構成が可能のようでした。
どちらを選ぶかは好みと案件次第？
「Next.jsとRemix、どっちを選べばいいの？」という問いに対しては、現時点では「どちらもそれぞれ良い」としか言えないかもしれません。
ただ、以下のようなポイントを押さえておくと、どちらのFWを使うべきか悩んだときに参考になるかもしれません。
・Vercelとの親和性が高く、静的・動的なハイブリッドアプリを作りたい → Next.js
・フォーム中心の構成でWebらしい挙動を保ちつつ、細かい制御もしたい → Remix
・すでにReact Routerに慣れている → Remix
・OSSや採用事例の多さ、安心感を優先したい → Next.js
今のところの正直な感想
まだRemixを触りはじめたばかりではありますが、「あれ、想像よりもNext.jsと変わらないかも」というのが正直な感想です。もちろん中身を深掘りしていけば設計の思想や細かい仕様の違いはあると思いますが、UIコンポーネントの構成やTailwind CSSの使い方など、開発体験としてはかなり近いです。
今後は、より本格的なページ構成やデータ連携の部分に触れつつ、それぞれの良さを探ってみたいと思っています。
おわりに
Next.jsとRemix、どちらもReact開発をさらに楽しくしてくれるフレームワークです。今回のように「まずはちょっと触ってみる」だけでも、それぞれの思想や設計の違いが見えてきて面白いです。
自分の用途や好みに応じて、フレームワークを選ぶ時代。これからも新しい技術にふれて、その変化を楽しんでいきたいですね。
