■ 1. AIによるNext.jsのデフォルト提案
- 脳死のNext.js提案:
- AIにプロダクトのコードを書かせると、ほぼ脳死でNext.jsを提案してくる
- 学習データにNext.jsのコードやチュートリアルが圧倒的に多いことが原因と推測される
- 提案の根拠の薄さ:
- AIは「このプロジェクトに最適だから」ではなく「一番よく見た形だから」で提案している場合が多い
- 生成されたコードを見ると全部にuse clientがついている
- 指摘すると即座に翻す:
- Tanstack RouterとHonoの方が良くないか、RSCを使うのか、と聞くとAIはその通りだと訂正してくる
- それならば最初からそちらで提案すべきである
- 問題意識:
- Next.jsが最適なプロジェクトは実在するが、それは全体のごく一部にすぎない
- AIが勧めるという理由だけでNext.jsがデフォルトになっている状況に納得できない
■ 2. Next.jsの強みが活きる場面は限定的
- 強みの正体:
- App RouterとServer Components、それに紐づくキャッシュ・レンダリング戦略がNext.jsの強みである
- 強みが効く条件:
- 不特定多数に配信する、SEOが重要な公開ページを大量に持つ場合
- ページごとの初期表示速度がビジネス指標に直結する場合、ECの商品ページなどが該当する
- サーバー側でしか触れないデータソースに、ページ単位で複雑に依存する場合
- 強みが関与しないプロジェクト:
- 社内ツール、管理画面
- ログインが必須で検索エンジンに露出しないもの
- 個人開発の初期フェーズで、まだユーザーがいないプロダクト
- 課題不在への解決策:
- これらは大多数を占めるにもかかわらず、RSCやServer Actionsが解決する課題自体を持っていない
- 持っていない課題への解決策を採用しても、得られるのはコストだけである
■ 3. Next.js採用で払う3つのコスト
- キャッシュ挙動の把握コスト:
- fetchのキャッシュ、Route Segment Config、revalidatePathなど、いつどこがキャッシュされ再検証されるかが極めて難しい
- バージョンごとに挙動が変わり、真逆になったこともある
- SSRが不要なプロジェクトであれば、この概念を学ぶ必要自体がない
- use client境界の管理コスト:
- Server ComponentsとClient Componentsの境界の引き方は、慣れないうちは頻繁に手戻りが起きる
- 境界を誤ると、意図せずクライアントバンドルが膨らむ
- 逆に、サーバー側で完結できるはずの処理がクライアントに漏れ出す
- これはNext.js特有の設計問題であり、SPAであれば考える必要がない
- Vercelへのロックイン:
- Next.jsの一部機能はVercelでのホストを前提に最適化されている
- 他のホスティング先では同じ機能でも挙動や性能が変わることがある
- フルスタックフレームワークの選択は、ホスティング先の選択肢を同時に狭めることを意味する
- Open Nextのような手段も出てきたが、デプロイに7、8分かかる、うまく動かないエラーが出るなど不便である
- コストに対する率直な疑問:
- ここまでのコストを払ってまでNext.jsを使いたいとは思えない
- 要らない時はもっと最適な手段を取ればよい
■ 4. 代替スタックの選択肢
- SPA + 軽量バックエンド:
- フロントエンドはVite製のReact/Vueで完結させ、APIはHonoのような薄いフレームワークで持つ
- フロントとバックの関心が分離されるため、片方だけ差し替えられる
- 自分は普段Tanstack Router + Honoで開発している
- 静的サイト中心ならAstro:
- ブログやランディングページのように大部分が静的なら、Astroなどの方が構成としてシンプルである
- 自分のサイトもAstroで構築している
- SSRが要るならTanstack StartかReact Router v7:
- RSCほどの複雑さを持たず、Request/Responseベースのシンプルなモデルでサーバーサイドレンダリングができる
- RSCまでいかなくとも、これで事足りる場合が多い
- 学習データ量の差:
- これらはNext.jsほど学習データが多くないが、AIもそこまで愚かではなく普通に書ける
- 学習量の差が問題になる時代ではない
■ 5. 課題から逆算したフレームワーク選択
- Next.jsが最適な範囲:
- SEO、初期表示速度、複雑なサーバー依存が絡む、公開向けの大規模なページ群を持つ場合に限られる
- 大多数のプロジェクトの実態:
- 社内ツール、管理画面、ログイン必須のSaaS、個人開発の初期フェーズはNext.jsが解決する課題自体を持たない
- 持っていない課題のために、キャッシュ把握、use client境界管理、Vercelへの密結合というコストだけを払うことになる
- 選択の基準:
- AIがNext.jsを勧めるのは技術的に優れているからではなく、学習データで一番よく見た形だからかもしれない
- 「AIがそう言うから」ではなく、自分のプロジェクトが実際に抱える課題から逆算してフレームワークを選ぶべきである
- 次にアプリを作る時の問い:
- 本当にNext.jsでなければ駄目なのかとAIに聞いてみるべきである
- そんなことはない、という答えが返ってくるはずである