あなたに Next.js は必要ありません — 私たちが Next から React に移行した理由
(comfydeploy.com)- ComfyDeploy ダッシュボードを Next.js から React に移行して得られた結果:
- ビルド時間が 3 分 → 18 秒に短縮
- ホットリロードが 200ms 未満に改善
- チームメンバーの満足度が大幅に向上
- 当初は Next.js を活用したフルスタックアプリケーションとして開始し、Drizzle と Server Actions によって型安全性とクリーンなコードを実現し、うまく機能していたが、次のような問題が発生:
- 特定のユーザーが原因で Vercel で 2,000 ドルの高額な API コストが発生
- API テストの複雑さが増加: Server Actions と API ルートが混在
- ビルド時間が遅く、ローカル開発環境も非効率
- 小さな変更でも SSR 全体のリロードが発生
- 問題点
- Next.js の複雑性増大: Next.js のオールインワン（フルスタック）なアプローチは、アプリの成長とともに開発の複雑さを招いた
- 私たちのダッシュボードは主に React ベースであり、Next.js のサーバー機能は必要ない
- Next.js から React への移行
- TanStack Router と Rspack を使って Next.js から React に移行
- 開発サーバー起動: 2 秒以内
- Vercel ビルド時間: 18 秒
- API 設定を改善し、不要な依存関係を削除し、コードを簡素化して生産性が向上
- TanStack Router と Rspack を使って Next.js から React に移行
- パフォーマンス比較
- Next.js 15（Turbo モード使用）
- 最初のページビルド: 10.4 秒
- React + TanStack Router + Rspack
- ルート計算: 200ms 未満
- 初期バンドルビルド: 1.67 秒
- Next.js 15（Turbo モード使用）
- トレードオフ
- 失ったもの
- フロントエンドとバックエンドコードの Co-location: フロントエンドとバックエンドを分離したことで、境界が明確になった
- Next.js のキャッシュ機能: リアルタイム更新データが多いため、カスタムキャッシュで置き換え
- 事前レンダリングと初期ロード: Static Generation の代わりに、より良い UX を実装 — もう無効なボタンは表示されない
- サーバーコンポーネントとアクション: サーバーコンポーネントの「魔法」は失われたが、より意図的な API 設計によって改善
- 得たもの
- API 契約設計の強化
- 必要な箇所でのみキャッシュを実装
- データフローと状態管理を慎重に設計
- 失ったもの
- 結論
- Next.js はランディングページや SEO のような用途には適しているが、ほとんどのプロダクトには過剰な複雑さをもたらす
- ランディングページ と SEO の作業には引き続き Next.js を使用
- ダッシュボード は Pure React + TanStack Router + Rspack に移行
- API は Python FastAPI サーバーを Google Cloud Run で実行し、必要に応じて自動スケール
- 適切なツール選び が重要であり、私たちにとって Next.js は過剰な選択だった
17件のコメント
うちの会社でフロントをnext.jsで
統一・マイグレーションする準備をしている時にこんな文章を読むことになって、いろいろ考えさせられますね……。
私たちはモバイル「アプリ」ファーストが可能なサービスだけを運営しているため、
SEOが必要な領域では React（またはそれに類するもの）をそもそも使わず、非常に軽量に保っています。
WebはSEO目的でのみ使い、アプリへ誘導しています...
「適切なツールを選ぶことが重要であり、私たちにとって Next.js は過剰な選択だった」
最後の一文が核心のようですね。
適切なツール選びのためには、こうしたさまざまな失敗を数多く経験してみることも重要だと思います。
SEO が必要だということは、コンテンツが中心だということなのに、
UI コンポーネント(?) と状態が中心を占めているので… SSR ISR Hydrate…のような奇妙な生命体が誕生…
かなり共感できる内容です。
私はSEOが必要な場合でなければ、Next.jsを導入することは決してありません。
上の文章のようにReactだけを使う場合は、利点が多いです:
詳しくは分かりませんが、ビルド時間にはかなり差があるようですね
React が他のフレームワークよりいろいろな面で遅いことを、まだ知らなかったようですね
速度は重要ではないからです。速度が重要なら、今でも expressjs が使われていることはないでしょう。コミュニティとライブラリの数が圧倒的に多いです
NextからReactへのマイグレーションに焦点を当てているようですね（笑）
Reactコミュニティが初期段階でCRAを捨ててフレームワークへ移行している中で、これに逆らうのが簡単な選択なのかは分かりません。
ほとんどはViteに移行したのであって、フレームワークは必要に応じて今でも使っています
とreact.devでも言っているので〜
興味深いですね。Reactと比べて、Nextのほうが重いのでしょうか？
Nextはプロジェクトのセットアップだけ試したことがありますが、非常に簡単にプロジェクトを構築して開発を始められました。
「シンプルに」<= これを実現するために、多くのトレードオフを伴う魔法(?)が隠れています。
共感します。Next.js の土台の下には、膨大な依存関係が隠れていますね……
Hacker Newsのコメント
多くの人が、アイデアを何十億人ものユーザーにスケールできるかどうかに過度に集中している。そのせいで、訪問者が5人しかいないWebサイトなのに Kubernetes を使うことがある。学生が Next.js を使って、HTML + CSS だけで簡単に書けるWebサイトを作っているのも見た
Next.js でプロジェクトを構築したが、使うのが複雑に感じられた。クライアントとサーバーで Cookie へのアクセス API が異なり、環境変数も
process.env.NEXT_PUBLIC_*で参照しなければならないなど、混乱しやすい。クライアントとサーバーの両方で最小限の変更で動くコードを書きたかったが、そうはならなかった。Next.js が提供するものに対して、学習コストとオーバーヘッドに見合う価値がないと感じるコードベースがシンプルになり、ページのレンダリング速度も速くなった。コミュニティが不必要にこうしたフレームワークへと追いやられているのは残念だ。ほとんどの人に必要なのは
npx rsbuild initだけだ。rspack と rsbuild を使って、シンプルなルーターと美しい単純さを手に入れたNext.js v14 のリリース以降使っているが、とても満足している。RSCs を使うことで、クライアント側の JS が無効でもアプリの多くの部分が問題なく動く。PHP アプリの素朴な強さがありつつ、型システムとインタラクティブな状態ベースのクライアントコンポーネントをビュー ツリーの「リーフレベル」にシームレスに組み込める
Rails と Hotwire のおかげで、React エコシステムの混乱から抜け出せた。状態管理ライブラリ、メタフレームワーク、データフェッチライブラリなど、選択肢が多すぎる。サーバーから来たデータをページに表示するという単純な作業を、わざわざ複雑にする必要はない
NextJS を使う CMS（PayloadCMS）で働いているが、NextJS はこれまで使った技術の中で最悪だ
Next.js、React、Vue のような重いフロントエンドフレームワーク/ライブラリを使っているほぼすべてのプロジェクトは、バックエンドでテンプレートを処理するライブラリを使ったほうが良いと思う。場合によっては EJS を使ったクライアントサイドレンダリングにも意味がある。なぜフレームワークを使うのか疑問だ
SEO とクローリング最適化のために Next.js を使っている。ページがクローリングされる必要がないなら（例: ログイン後のダッシュボード）、Next.js は不要で、素の React のほうがシンプルだろう
Next.js がデフォルトの出発点になっていることに驚いている。2〜3年前と比べると大きな変化に感じる
Vike を使って NextJS アプリを置き換えようとしているが、満足している。邪魔されることなく、自分の望むやり方で構築できる
アクセス数5人のアプリにk8s……すごいですね