前提
※ ポエム記事なので、全て私個人の主観です🙏
結論と主旨
先に書いときます。
- Next.js は非常に便利。とても良い技術で、慣れると最高
- Next.js はそんなに好きじゃないですが、今後も使います（市場が大きい内は）
- でも、初心者にはやっぱり「オススメ」ではない（＝初心者向けではない）
- Next.js 以外にも色んな技術使ってて、常に別の技術採用時にも対応できるようにはしていますし、今後もそうします
え、嫌いなの？
別に、嫌悪するほど嫌いじゃないです。ただ、「うわぁ、面倒くさい！」って感じてしまうシーンが多かったとは思います。結果、今のところは嫌気がさしてます。
でも、便利だし優れた技術だとは思います。
激しい変化が落ち着いたら前向きに使うし、今後も利活用する記事とかは書くつもり。今回の主旨は、「初心者向けじゃないよ」という意見です。
じゃあ何で使ってるの？
- 使う理由は市場の要求が多いからです。仕事である以上、技術者としてニーズに応えられる能力は持ち合わせていなければいけないと思っています。
- 使わなくて済むなら使わないです。だって面倒臭いんだもん（２回目）
- 初心者向けではないだけで、面白さはあります。変更が安定してくれれば、楽しいは楽しいので喜んで使う
- ただ、バージョンアップが激しすぎて追っかけるのがダルい。フロントエンド技術は戦国時代なので、安定なんてしないのでしょう
前知識
今日の「Next.js 大人気！」がやってくるまで、私が印象に残っているフロントエンド開発の歴史的背景を共有します（所々間違ってるかもなので後で修正します）。
SPA 時代に突入
唐突ですが、アイドル風に説明します。
- SPA 御三家が華々しくデビュー
-
Angular（2010）※ フレームワーク
- プロデューサー: Google もと やすし
-
React（2013） ※ ライブラリ
- プロデューサー: Facebook んく（現: Meta）
-
Vue（2014）※フレームワーク、Angular と React のいいとこどり
- プロデューサー: 元 Google の天才エンジニア Evan You 氏
-
Angular（2010）※ フレームワーク
- Angular vs React vs Vue 戦争
- Angular が敗退
- AngularJS が微妙すぎた上に、v2 で破壊的な仕様変更
- こ、こんなの使えるかぁー！（ちゃぶ台返し）
- 大量の人気が React と Vue に集中する
- React Native が登場し、モバイル領域でもマルチに活躍する人気タレントに
- React はライブラリであるために限界があり、色んなツールを組み合わせてベストプラクティスが模索され始める
- Flux アーキテクチャの概念を拡張した Redux が登場。React の公式に認められ正式メンバーとして加入
- 単なる UI ライブラリから、エコシステムへと進化を始める
Next.js が登場（Nuxt も）
- Next.js 「私が来た！」（Nuxt『私も来た！』）
- React でできることが限定的だったので Next.js が登場
- （当時の）React は クライアントサイドレンダリング（CSR）特化なので、SSR に対応するため
- 次第に人気が高まり、世界的アイドルフレームワークに
Remix vs Next 戦争が話題に
Remix の共同創業者の一人である開発者 Kent C. Dodds 氏が、「Why I Won't Use Next.js（私が Next.js を使わない理由）」という記事を出して、界隈で話題に。
Next.js を、"Too much magic"（過ぎた魔法）、"Next.js is eating React"（Next は React を侵食してる） と指摘する。
その後、アンサー（反論）記事として、
Vercel の VP of Developer Experience（当時。現在は VP of Product） である Lee Robinson 氏が、「Why I'm Using Next.js（私が Next.js を使う理由）」を発表して、また話題に。
※ ちなみに、お二人は仲の良いご友人のようです🖐️
その頃 Vue は？
- Vue 3がリリース（2020/9）
- Vue 2からの大規模な仕様変更。Composition API の正式導入など
- Nuxt 3 プレビューリリース（2021）
- Vue 3 に SFC のセットアップスクリプト構文が導入（2021）
- Nuxt 3 正式リリース（2022）
- Vue 3 のネイティブサポート,Nitro エンジン、Webpacker の廃止など大規模な修正
- Vue 2/Nuxt 2 を採用していた現場から悲鳴が上がる🔥
- 機能は素晴らしいのだが、急な移行が難しい現場が多発し、各現場で別技術を採用し始める
- こ、こんなの使えるかぁー！（ちゃぶ台返し）
- Vue 離れが一気に加速
- Vue 3.3 リリース（2023）※ でも人気低迷
- Suspense や Reactivity Transform などの新機能が追加
- Nuxt 3.1 リリース（2023）※ でも人気低迷
- Nitroの最適化やVue 3.3のサポート
React は 18 へ、そして Next は 15 へ
人気は絶好調！無双状態！！「Next.js が通るから道を開けろ！」 モード
ユニークな技術は次のステージへ旅立とうとしています。
条件付きですが、正直便利なんです。すごいんです。
初心者向けじゃないけどね。
Next.js に嫌気がさした経緯
バージョンアップ内容がもう少し落ち着いてくれたら喜んで使います。変更が激しすぎて関係各所での対応が面倒になってるのが理由です。
React の学習コスト
React はとても素晴らしい技術だけど、全てが長所ではありません。
JSX 前提
ここでは、DeNA 社が開発した AltJS の方の "JSX" ではなく、Meta 社（開発当時は Facebook）が開発した方の "JSX" という言語を指します。
React は、「レンダリングロジックは他の UI ロジック（イベント、状態管理）と連動し、一緒に管理すべき」という考えに基づき開発されています。
そのため、Meta は JSX（JavaScript XML）という、JavaScript の中にマークアップ言語を書くことができる言語 を開発し、他技術の様にコンポーネントの構成言語を分ける（HTML/JavaScript を別ファイルにする）のではなく、まとめて書ける JSX を採用しました。
初心者は、まず HTML/CSS/JavaScript を覚えた後に、JSX という言語を覚えなくてはいけません。なんなら、今は TypeScript （TS）が主流なので、TS を追加で覚えるハードルが存在し、型付き JSX である TSX も知る必要があります。
使い慣れたら簡単かもしれませんが、まずこの時点で「初心者向き」とは言えません。
だんだん疑問符がつくバージョンアップが増えてきた
最初はまだ良かったですが、いつからか「ん？お、おう」と思う様になり（どのアプデだったか忘れたので後で追記するかも）、React Server Components とか辺りで、個人的にはいよいよ「うーん」とか思ってきました。
技術的には素晴らしいアプデだとは思っていますが、良くも悪くもユニークすぎて暴走状態にも見えます。
ファンとして好きだった芸能人の変貌ぶりに「急にどうした？」ってなった時の心境に近いかもしれません。
Next は React のフレームワークなので
React と Next は、技術としてだけでなく、"ビジネスレベルでズブズブ" な印象です。
React の公式ドキュメントで Next を推奨したチュートリアルになっていたり、どっちがどっちに合わせて新機能リリースしてるのかとさえ思うシーンもありました。
Next.js は React のフレームワークなので、React の学習コストの上に、更にNext.jsを覚えるという学習量が増えます。
React が改変されると、Next.js（他のReact系フレームワーク含め）もそれに引っ張られて変わります。
「React のこの新機能に対応しました！」みたいなバージョンアップがあります。覚えること２倍２倍。
特定の技術で人気のライブラリ使ってたら、本流の技術と周辺ライブラリや技術の両方を気にしなければいけない、あの感じ。
こんなに学習するなんて聞いてないよ感
最初の "Anguler vs React vs Vue" の三すくみ時代から考えると、
「React が学習コスト低くてモダンで素敵！」 と言われて使ってきた人達が、流行の波に乗ってたら色んな関連ライブラリのベストプラクティスに追われ、いつの間にか Next.js が登場してズブズブになり、気がついたら Next.js のバージョンアップを追い続けなければならない泥沼に引きずり込まれてる印象です（私がそう）。
Zero Config
これは賛否あると思いますが、やっぱり「何も設定しなくても勝手によしなに動いてくれる」というのは、入りやすいですが、慣れたらダメなやつだと思ってます。
そもそも、フレームワークが内部的に何してるかわからないこと初心者ならどの技術でもありますが、Next.js はブラックボックス具合が他と比べて強めに感じます（「魔法」と言われる要因の１つ）。
「（なぜ動くかわからないけど）Qiita のコードをコピペしたら動いた！」みたいなやつに近いと思っています。
Next.js じゃなくても
当然のことですが、同じことができる他の技術が名乗りを上げ始めてきたので、昔言われていた「Next.js である理由」がほぼ無くなってきました。
その結果、当然ですが、更にユニークな機能追加や優位性を示すバージョンアップを Next.js がする様になりました。
その末に誕生したのが、何してるかわからないけど色々できる "魔法の様なフレームワーク"。
フレームワークは大抵魔法になりがちかもしれませんが、色んなフレームワーク触ってみてはいるからこそ、個人的にその度合いが Next.js は激しい印象です。
「そんな機能いるの？何に使うの？」「もやは何がしたいのかわからない」という意見も散見される様になってきました。
過去の背景を追っている人しか理解できない充実機能
バージョンが低い頃の Next.js から追っかけてる人は、なんでその機能があるのか、どうなっているのか、過去に比べて何が劇的に良くなったのか、などが享受されています。
しかし、「初心者」の観点で見たときに Next.js は Too much な「魔法の箱」です。
中には問題なく追える人もたぶんいますが、過去に比べて、純粋に学習コストが高くなってしまいました。
バージョンアップが大変
これはどの技術にも言えなくはないことですが、Next.js はそれが特に顕著な印象です。大変な理由はもう上記でたくさん述べました。
Next.js は最新状態を保てば、多大なメリットを得られます。逆に言えば、ちょっとアップデートに食らいつくのを置いてかれると、「終わりの始まり」です。
「Web 標準」からどんどん遠ざかっている
「Web標準」とは、Web アプリケーション構築において、世界的に推奨されている規格やガイドラインの総称を指します。
現代においては、W3C(World Wide Web Consortium) や ISO 等の国際機関が策定・公開している仕様がそれに当たると思います。
平たく言うと、HTML, CSS, JavaScript の文法ルールとかですね。
要するに、そこで公開してみんなが使ってる記法やルールとは、もはや別物に見えてしまう特殊な情報と化している印象が強いです。
JSX 然り。React/Next の書き方なんて、そこ以外で使わないでしょう。特に Next.js は、魔法すぎて、標準的な技術の書き方からどんどんユニークになっていってると感じました。
Web 標準から遠ざかると言うことは、仮に Next.js が廃れて別の技術に以降しようとなっても、そこで覚えたことが他で使いづらいと言うことです（＝ 可搬性が低い）。
Next.js しかやってこなかったフロントエンジニアは、他で潰しが効かなくなってしまいます。
具体例
例えば、他のフレームワークなら、標準の Web API である Fetch、Observables、HTTP クライアント などを直接利用できるよう設計されています。一方、Next.js は React のライフサイクルメソッド や useXXX みたいな独自の API に依存する部分が多いです。
ルーティングシステムも、他のフレームワークは標準の History API を利用した URL の変更に対応しやすいですが Next.js のファイルベースルーティングは便利だけど標準の書き方とはだいぶ印象が変わります。（状態管理含め、この辺が大体 React 初心者の最初の壁）
ただ、最近は Next 12 以降で Middleware で Web API をサポートし始めたり、Route Handlers においてより Web 標準に近づいてはきました（それでも独自性の強さをブログで指摘されましたが）。
また、そもそも「React は Next と一緒に学ぼう」になっていますので、React がそもそも純粋関数の思想をベースに持つなどの背景は、チュートリアルでは追えない印象です。なので、初心者が「副作用ありまくりのコンポーネント群」を作ってしまう節があると感じました。
オレオレ実装のサラダボウルが生まれる
フロントエンドのフレームワークは特に 「ぼくが かんがえた さいきょうの ふぁいるこうせい」 みたいなソースコードが出来やすいが、Next はバージョンアップの仕様変更で、ディレクトリ構成の推奨やデフォルトがよく変わった。
そのため、src ディレクトリの有無、pages ディレクトリの有無、components ディレクトリはどこに置く？とか lib, util ディレクトリの要/不要 とかのバラツキが、各個人の慣れたバージョンによって異なる可能性が高い。
結果、Next.js を覚えた人がチーム開発をすることになった場合、「オレはこの構成に慣れてるんだが」みたいなのが起きやすくないかなと思ってしまった。
ベンダーロックしやすい
いわゆる「ベンダーロック」とは、特定のベンダーに極端に依存する状態に陥ってしまうことです。そのベンダーが使えなくなってしまったら一瞬で "詰む" ということです。
色んなプラットフォームで Next.js はデプロイ可能ですが、Next を効率良くフル活用すると考えた時に、どこにデプロイする？…となったら答えは 「Vercel」 です。
だって公式だし。新機能追加した時に最初に対応するのはココでしょうし。しかも、「Next.js を使う時、こんなことを心配しなくても大丈夫。そう、Vercel ならね」 みたいな設定とかたくさんあります。
逆に言えば、天才的な Vercel 様 に依存してしまうリスクが高くなるということです。
プロジェクトの長期安定運用には向かないかも
ほとんどのプロダクト開発は「チーム戦」です。
つまり、開発作業可能な人材 が揃っているかどうかが大事で、「その技術扱えません」という人が来られても困るので、なるべく人が補充しやすい技術選定であることも大事なのです。
例えば、ある現場では「当時に流行ってると聞いて、Next 10 で現場に導入したけど、その後バージョンアップ対応できてなくて古いまま」なのに、
人不足で募集しても 「いやー、Next 13以降なら触れるんですけど…」 みたいなミスマッチも容易に想像できますし、「Next 10！たぶんさわれます！」（エンジニア） とか、「ウチの〇〇、Next 10 いけます！」（営業） とかが現れたけど、実際に現場にアサインさせてみたら全然できなかった…みたいな 事故 も起きます。
しかも、時が経つほどこの解決が難しくなります。
よくわからない内に、人材コストだけお金かかるけど、なかなか改善しない開発プロジェクト** が増殖していきます（もしかして、もうしてる？🤔）。
Next.js に限った話ではないのですが、他の技術と比較して変更が激しい印象です。
バージョンアップの激しい Next.js で、古いバージョンから新しいバージョンに精通しているエンジニアがどれだけいるのでしょうか？…という疑問が、どうしても着いて回ります。
個人開発や小規模開発なら全然アリだと思う。でも、やはり初心者は他から触ったほうがいいかな。
特大の"時限爆弾"になりやすい
ここで言う "時限爆弾" とは、「表面上の緊急性はないけど、いつかインパクトのデカい問題を起こしそうな技術的負債」を指します。
- 公式サポートも切れてすっかりレガシーになってしまった
- バージョンアップとか根本解消したいけど、影響範囲も広く・根深くて今更いえねぇ
- 今まではなんとかしてきた、まだ（表面上は）致命的な問題になっていない
- いつかトラブル起こす未来しか見えてこないけど、今じゃない、今じゃないんだ
- ネットの記事も最近見つけづらくなってきたな。公式調べてもこのバージョンのはもう載ってねぇや。ハハッ！
これも Next.js に限ったことではないのだが、前述の「Web標準から遠くなってる」＆「ベンダーロック」まで含めると、Next.js は 特大の時限爆弾 になる可能性がある。
現場で、「なんで Next.js なんですか？」って聞いたら大体答えは "流行ってるから" 的なのがほとんど。別にそれは悪いことでないが、その後も上記のリスクを加味してメンテし続けることを忘れてはいけない。さもなくば "時限爆弾" になる。
ミーハーな技術採用が増えてきた
まず、前提として 「流行ってる is 正義」 が日本は多すぎる印象。さすがミーハー大国ジャパン。
Next.js は国内外から見ても非常に人気です。ガンガン使われている。
できた方が、仕事のチャンスも多いでしょう。今は。
確かに "人気" は大事です。案件求人数にも影響するし、人材流動性にも影響するので。
けど、「求人数」とか「案件数」とか、スナップショットで数値が高いだけで推奨するのはリスクが高い。
「流行ってる技術」を最も口にするのは、スクール経営者や営業的立場に近い人であり、彼らのポジショントークが割合多いことを、私たち技術者は忘れてはいけない。
なぜなら、「じゃぁ、その技術が流行らなくなった時はどうするんですか？」という問いに、彼らの答えは限られてくるからです。
上記みたいなリスクやデメリットを提示しても素晴らしい回答が返せる営業とかだったら、信用できるかもしれない。
短くまとめると
素晴らしい技術だけど、覚えることが多すぎるし、変化も激しいし、潰しが効かないから、初心者向きじゃない。
じゃあ何が良いのよ
全くの初心者でも、もともとバックエンドや他の技術を触っていた技術者でも、「本格的にフロント初めてやるけど、どうしよう？」となった場合ですが
正直、正解はないです。
だって、利用者（デベロッパーやエンドユーザ）の要求・要件にもよるし、開発現場がどう回されているのかとか、現場参画メンバーの平均技術レベルにもよるし、プロジェクト規模にもよるし。「結論、これが正解」というものは当然ないのです。
・・・が、強いて言うなら…👇
- Next 触る人は、まず JS のお勉強と、ベストプラクティス追いかけ続けるのは人一倍やりたいところ
- React にこだわらないなら、Svelte でもいい
- React をどうしても使いたいなら、Web標準意識が強い Remix でもいい
- Rails とか Laravel とか既に使ってるなら、もうそれだけで終わらせよ
- サーバサイドに Go とか NestJS 使ってるなら、画面は React だけでいいじゃん
- なんでもいいなら、v19 以降の Angular 使ってよ（私の趣味）
- あと静的なブログやコーポレートサイトなら Astro いいよ、Astro（最近の推し）
結論と主旨（再掲）
改めて書いときます。
- Next.js は非常に便利。とても良い技術で、慣れると最高
- Next.js は好きじゃないですが、今後も使います（市場が大きい内は）
- でも、初心者にはやっぱり「オススメ」ではない
- Next.js 以外にも色んな技術使って、常に身軽に動けるようにはしていますし、今後もそうします
※ 現役の技術者は、フロント触る人なら一回触っておいた方がいいと思う。食わず嫌いは良くない🐟
おまけ：SNS でも新記事を告知
この Qiita アカウントでは、技術的にクリティカルなエラーの解消方法や、トレンド技術を具体的に活用するノウハウを中心に記事を公開（考え方などのポエム記事は控えめにしたい）。
X（旧：Twitter）で、ITや生成AIなど技術的な内容しか吐き出さない専用アカウントがあり、新記事の公開時にはこちらでも周知します。
また、Xでは、お気持ち投稿は控え、ひたすらエンジニアや生成AIに関心がある人向けの情報だけを投稿していくつもりです。（※ たまに Udemy や node や Tips などで有料コンテンツの投稿もしますが、悪しからず🙏）
今後の情報にもご興味があれば、お気軽にフォローしてください👇