巷の「ReactとNext.jsの比較」はここがおかしい、というか比較すること自体が微妙
(WIP まとまったら Qiita とかに上げるかも)
TLDR;
「React と Next.js を比較」という記事で、
Next.js と比較できるのは「フレームワークなしで React を使うという選択肢」であって、「React そのもの」ではない。
✅️ React を使うのに 「フレームワークあり」 vs 「フレームワークなし」
❌️「React」 vs 「Next.js」
それはそうと、「create-react-app の機能・特徴」のことを、「React の機能・特徴」であるかのように書いてしまっている記事が多い
create-react-app 自体が擬似的なフレームワーク（といえそう）
そもそも、create-react-app は今は更新されてないので create-vite を使うべき
https://scrapbox.io/files/6632fbb6ee33ba002449cf1f.png
フレームワークあり or フレームワークなし
【フレームワークあり】 React はライブラリであり、Next.js はそれをラップしたフレームワークであることに注意が必要。
また、Next.js 以外のフレームワークとして、静的生成に特化した Gatsby、新興の Remix, Astro なども選択肢に挙がりうる。
【フレームワークなし】 create-react-app はかつて「フレームワーク無しで開発するためのスターター」として開発されていましたが、今（2024/03/23時点）は開発がストップしています。代わりに、同じ立ち位置で開発が止まっていない create-vite を使いましょう。 (将来は、「公式スターターとして、各種フレームワーク or vite に誘導する」ツールとして再出発する予定だそうですが、それはまた別の話…)
React 公式は、「フレームワークあり」という選択肢を推奨している
create-vite デフォルトそのままだと品質が不十分だと考えていそう
SG も行わなず、フル CSR （最初は真っ白な画面→初期描画）
ルーティングおよび、ルーティングに連動したコード分割機能の不十分
語群
SG: Static Generation 静的生成
SSR: Server Side Rendering サーバー側レンダリング
CSR: Client Side Rendering クライアント側レンダリング
Pages Router / App Router
Next.js は、旧世代(Pages)と新世代(App)の2つのフレームワークが並び立つような格好になっている。
SPA: Single Page Application
MPA: Multi Page Application
ベン図
「自分で書く」ものと「フレームワーク等が under the hood で呼び出している」ものの区別がついてないけど、とりあえずベン図にしてみた
https://scrapbox.io/files/6632fbb6ee33ba002449cf1f.png
概観
React で実現可能なことは、たいてい Next.js でも実現可能
いっぽう、Next.js では対応できない細かな調整のためにフレームワークを使わず React の renderTo〇〇 などの基盤的機能を直に使うケースはあるはず
例1 : 既存のフルスタックなMPA構成に組み込む場合
例2: Gutenberg
React 単体ではボイラープレートだらけなので、基本的にフレームワークを用いることが推奨される
create-vite, create-react-app といった、フレームワーク無しのスターターは、そこをある程度、補っている
ふつう、この始め方を指して「Next.jsを使わずReactを使う」ということが多い
Next.js は、思想がかなり強く、徹底的に最適化しようとする
なので、不具合・エラーに対処するために追加知識が必要になるケースも多い
CSR のみではない、SSR, SG 対応のための知識
Next.js 特有の知識
特に、SG / SSR / CSR 周りは取っ付きにくい
それから逃げるために create-viteS に手を出すのも、アリ…かな？
星取表(?)
1. ルーティング
React
無し。開発者の自由に任されている。
MPAなどに組み込むことも可能
クライアント側ルーティングのライブラリもある
React Router
TanStack Router
Next.js
ファイルベースの高度なルーティング機能
ハードナビゲーションではMPA的に、ソフトナビゲーションではSPA的に振る舞う
a 要素の代わりに next/link を使う
history を使った遷移の代わりに useRouter を使う
SSR (サーバーサイドレンダリング) と SG (静的生成) 機能も内包されている
2. SG / SSR / CSR
React
SG / SSR したいときは、SG / SSR のための機能(renderToString 等)を自力で呼び出すことになる
createRoot のみを使った場合は、CSR のみ
create-react-app, create-vite はデフォルトでこれ
Next.js
ルーティング機能に組み込まれている
自動的に最適化しようとするため、左側に寄せよう(なるべくSGしよう)とする傾向がある
Pages Router では静的に決まる部分は SG、決まらないけど、サーバー側からのデータ取得で決まる部分は SSR …
App Router ではデフォルトで Static Rendering、動的機能を使ったとき初めて Dynamic Rendering に切り替わる
逆に、SG, SSR されてしまって困る場合がある。
起きる問題の例:
SSR 非対応ライブラリ
ハイドレーションエラー
対策
Recoil, TanStackQuery 等は、ハイドレーションエラー回避のための機能を備えている
逆に、React Server Component は CSR されないので安全？
回避が難しく、CSR のみで妥協できる場合は、思い切ってオプトアウトすると良い
3. その他ツールチェーン (リンター、TypeScript、CSS バンドル等)
React
React はライブラリなので無い。
create-react-app, create-vite など、スターターに任せる等の方法がある
まあでも、最近はゼロコンフィグ化が進んでるので、そんなに辛くないかな…？
Next.js
ゼロコンフィグで、かなりの機能がカバーされている
React Server Component も、バンドラを利用する機能なので、ここに入る？
4. Next.js が備える、その他の特徴
サーバー側の諸機能
API Routes (App Router では Route Handlers)
React (canary のみ) の Server Actions も使用可能
BFF (Backend for Frontend) としても使える
Next.js 単独でフルスタックな構成も可能
画像最適化
next/image
《バンドル→サーバー側でのリサイズ→imgタグのマークアップによる最適化》と一気通貫で面倒を見ることが可能
一部の機能だけを使う・サーバー側の機能をオプトアウトする等、色々と設定できる
（機能が多すぎてややこしくもある）