Next.jsは最高のフレームワークではない。最も「確実な選択肢」なのだ。

Next.jsは最も利用されているReactフレームワークだ。同時に、最も嫌われているフレームワークの一つでもある。

調査によると、利用率は高いものの、満足度は低下している。人々は複雑さやApp Routerについて不満を漏らしている。肥大化している、あるいはVercelの使用を強いてくる、といった声だ。

これらの中には事実もあるが、そうでないものも多い。

ほとんどの人は、間違ったツールを選んでいるか、ツールの仕組みに抗おうとしている。そして、ツールのせいにするのだ。

私は長年Next.jsを使って開発を行ってきた。ミスが実損につながるようなプラットフォームでもNext.jsを採用してきた。私の見解は以下の通りだ。

Next.jsは最高のフレームワークではない。最も「確実な選択肢」なのだ。この二つは全く別物である。

実践的なプロジェクトには多くのニーズがある。コンテンツサイトが必要な一方で、ダッシュボード、エディターのプレビュー、そして大規模なスケーラビリティも求められる。

単一のタスクにおいては、他のフレームワークが勝ることもある：

  • Astroは静的サイトに最適だ。
  • SvelteKitは開発者体験（DX）と軽量な出力において非常に優れている。

しかし、要件が複雑になったとき、Next.jsが勝利する。

Next.jsには、自前で構築しなければならないような機能が組み込まれている：

  • Incremental Static Regeneration：フルリビルドなしでページを更新できる。
  • Draft Mode：編集用のプレビューを容易に行える。
  • Edge runtime：高速なミドルウェアや認証を実現する。
  • StreamingとSuspense：低速なデータの処理を扱う。
  • Server Actions：個別のAPIなしでロジックを実行できる。

また、Next.jsには巨大な引力がある。Reactの上に構築されているからだ。AIモデルの学習データ量も膨大である。AIを使ってNext.jsのコードを書く際、パターンが至る所に存在するため、より精度の高いコードが生成される。

トレードオフは確実に存在する。それらを理解しておくべきだ：

  • 非常に「opinionated（設計思想が強い）」である。その機能が不要な場合、フレームワークと戦うことになる。
  • ポータビリティ（移植性）が課題となってきた。長らくVercelから離れることは困難だった。
  • App Routerへの移行は混乱を極め、分かりにくかった。

教訓はこうだ。Next.jsを採用することは、「オールイン（全賭け）」の決断である。

フレームワークの設計思想を尊重し、意図された通りに使えば、それは強力な武器となる。もしその設計に逆らって無理に動かそうとすれば、永続的なコストを払い続けることになる。

かつて、Next.jsのルーティングルールを壊すようなカスタムアーキテクチャを構築したチームを見たことがある。彼らのエンジニアリングとしての選択は理にかなっていたが、フレームワークと衝突してしまったのだ。彼らはSEOやリンクといった問題に対して、回避策（ワークアラウンド）を書くために何ヶ月も費やすことになった。

問題はフレームワークではなく、適合性（フィット感）だった。

数年間にわたって維持しなければならない複雑なものを構築する場合、Next.jsは「最も失敗の少ない選択肢」となる。それが設計された目的のために、Next.jsを活用すべきだ。

出典: https://dev.to/fredcorr/nextjs-isnt-the-best-framework-its-the-most-reliable-bet-5e2c