フロントエンドフレームワークの一長一短で「メタフレームワーク」に分類したNext.jsを見ていきます。
Reactの上に建てる、もう一段の仕組み
Reactとはで見たとおり、Reactは画面のUI部分だけを引き受けるライブラリで、ルーティング（URLごとに、どの画面を表示するか決める仕組み）やサーバー側の処理は含まれていません。Next.jsは、そこにルーティング・データ取得・サーバー側レンダリングなどをセットで載せる「メタフレームワーク」です。Reactを開発したMetaとは別に、Vercel社が開発しています。
何が「セット」になっているか
- ファイルベースのルーティング：フォルダの構成が、そのままURLの構造になります。ルーティングの設定ファイルを自分で書く必要がありません
- レンダリング方式の選択肢：SSR（リクエストのたびにサーバー側で画面を組み立てて返す）、SSG（あらかじめビルド時に組み立てて配る、静的生成）、ISR（SSGを一定間隔で作り直す）——ページごとに使い分けられます
- API Routes / Route Handlers：画面用のコードと同じプロジェクトの中に、サーバー側の処理（外部からデータを送り受けできる窓口となるURL、APIのエンドポイント）も書けます
- 画像の最適化のような、ビルドまわりの最適化も標準で付いてきます
Vercelとの相性
Next.jsを開発しているVercel社は、Vercelというホスティングサービスも運営しています。そもそもVercelとは何かで書いたとおり、git pushするだけで公開まで自動でやってくれる仕組みは、Next.jsのプロジェクト構成をあらかじめ理解した上で動いています。Vercelで公開されるアプリとして、実際にもっとも遭遇率が高いのがNext.jsです。
決めることが減る代わりに増えるもの
素のReactでは、「ルーティングは何を使うか」「サーバー側の処理はどう書くか」を自分で決める必要がありました。Next.jsを選べば、それらはあらかじめ決まった形で用意されていて、迷う場面が減ります。
一方で、レンダリング方式の使い分け（サーバー側で処理するコンポーネント（画面を組み立てる部品）と、ブラウザ側で処理するコンポーネントを区別する、といった考え方）という、素のReactにはなかった新しい概念が増えます。「セットになっている」ことは「何も覚えなくていい」ことと同じ意味ではなく、Next.js自身の流儀を新しく覚える必要があります。
サーバー側レンダリングは、検索エンジン対策（SEO）や最初の一画面を速く届ける用途には強い一方、フロントエンドフレームワークの一長一短で書いたとおり、絶えず操作され続けるタイプのアプリでは、この仕組み自体が足かせになる場合があります。実際に響くのはSSRそのものというより、ルーティングなど周辺機能までまとめて読み込まれるオーバーヘッドであることが多く、Next.js自体はクライアント側だけで完結させる書き方も選べるので「Next.jsだから遅い」わけではなく、既定の作りが、周辺機能ごとサーバー側レンダリングに寄っている、という理解が正確です。
まとめ
- Next.jsは、Reactの上にルーティング・レンダリング・API機能をセットで載せるメタフレームワーク
- Vercelとの相性が特に良く、Vercel上で書かれるアプリとしてもっとも遭遇率が高い
- 決めることが減る代わりに、レンダリング方式という新しい概念を覚える必要がある
- 常に操作され続けるアプリでは、サーバー側レンダリング寄りの既定の作りが向かないこともある