はじめに
だいぶ前にこんな記事を書きました。
この時は「Nextと言えばSSR！という時代が終わって、クライアントで色々やろう」っていう流れだったわけですが、Next13 からはまたサーバサイドでのレンダリングに注力されるようになりました。
その辺りから、徐々に「Next つらい」な声が目立つようになってきた気がします。
数年間Nextを使っていた僕も、実は今は使っていません。
が、これは Next がだめだ！とか言いたいのではなく、徐々に Next というフレームワークが使用者を選ぶようになってきたという表現の方が正しいのではないかなと思います。
この記事の目的
「Next を使うべき？使わないべき？」という疑問に対して、判断材料となる情報を提供します。
Web アプリケーション開発の歴史を振り返り、なぜ Next がここまで使われるようになったのか、そしてなぜ今その潮流が変わってきているのか、それを明らかにします。
対象読者
「今ならやっぱり Next 使っとけば問題ない？」
「Webフロントそこまでちゃんと追ってないけど、今ってどんな状況？」
という方にとっては概観を掴む資料の一つになるかなと思っています。
前置き
この記事は技術そのものではない情報を多分に含む大長編です🤣
理解を深めるためにめちゃめちゃ遠回りをするので、9割くらいエンタメとしてお楽しみください。
個人的には、ツールを使う上でその出自や背景を理解するのは非常に重要だと思うので、そういうのがちょっとでも気になれば、ぜひご一読ください。
また超主観で偏って書いていますので、自分の記憶違いや、こういう見方もあるよね、などありましたらぜひコメントください。
Webアプリケーションフレームワークの歴史と、取り組んできた課題
そもそもWebアプリケーションのフレームワークに求められているものとは何なのか？ということを歴史から紐解き、解くべき課題という観点で今のNextの価値の変遷について見ていこうと思います。
そもそもなぜ僕たちが使う技術が時と共に変化するのかと言えば、それは 現実に起こる新しい課題に対して新しいアプローチが必要になるからです。 実際に採用される技術の変化は、必ず時代の要請と共に語られます。
では、Webアプリケーションの課題というのはどのように変化してきたのでしょうか。
Nodeを筆頭とした、JSファミリー興隆の背景
近年のWebアプリケーション開発に欠かすことのできないNodeですが、JSおよびNodeがなぜここまで人気になったのかを追いかけると、Webアプリケーション開発が扱ってきた重要な課題が見えてきます。
僕がWebアプリケーションの開発を始めたのは2015年辺りで、それはES6が登場した年でした。
当時はWebアプリケーションフレームワークと言えばRailsでしょという時代で、例に漏れず自分もガリガリRailsを使っていたのですが、同時にNodeの地位がぐんぐん上がっている時代でもありました。
当時のスタートアップはC向けサービス全盛の時代だったので、サービスを公開するということは多くの消費者ユーザーに突然ガッとアクセスされるということを想定せざるを得ない状況でした。
そうしたクライアントの増加をC10K問題（同時に接続するクライアントが10,000などの多数になったらどう対処する？という問題）などと呼んでいて、それに対応できるNodeがこれからの時代に適しているぜ！という触れ込みで、ノンブロッキングI/O（I/O中でもプロセスが止まらずに処理を続けるという仕組み）という言葉が次世代の象徴のような役割を担っていました。
またこの時期はIoTという言葉も流行しており、センサーを使って常時データを受け付けるような仕組みを作ったりすると、クライアント（センサーデバイスなど）からのリクエストが常時飛んでくるようなケースも増えていました。大抵センサーデバイスはリッチな環境を期待できないため、大量のログデータをデバイス側に保持させる選択はなかなか取れず、データの欠損があると損失なので、基本的に常にサーバにログを送信し続けたい状況になります。それゆえ、リクエストが重かったとしても常時やってくるリクエストを捌き続けてくれるという安心感がNodeにあったりしました。懐かしい。
つまり2015年辺りのアプリケーションは、 「クライアントの数めっちゃ増えてるよ！どうするよこれ！」 というのが一つの注目の課題でした。
それに対応するようにNode人気も加熱していったわけですが、Node人気については さらにもう一つ重要な「JSニーズの爆発的な拡大」という要因があると考えています。
それを理解するためには、ここ10余年ほどのアプリケーション全般の歴史が鍵になります。
ネイティブアプリから読み解くJSニーズ
スマホの登場から10年ほどは、アプリケーションの世界はやはりネイティブアプリがメインストリームだったと思います。 この時代のソフトウェアはスマホのネイティブアプリが牽引していました。
iPhoneが日本に上陸したのは2008年です。当初、iPhoneのアプリで主流だったもの、覚えていますでしょうか？
タッチスクリーンやジャイロセンサーが目新しく、また携帯できるコンピュータとしてはガラケーと比較して様々な性能が良く、そうした新しいデバイスを活用したアプリがたくさん出ました。
そう、スマホが浸透し出した頃のアプリはゲームやツールなどが主流でした。
その構造が徐々に変わり始めるのが、2012年前後からです。
| 2010年 |
|
| 2011年 |
|
| 2012年 |
|
| 2013年 |
|
| 2014年 |
|
ゲームや簡単なツールではないサービスタイプのアプリのインパクトが世界的に増してきたのがこの時期です。
「UI/UX」「UX」という言葉のGoogleトレンドの推移の結果がこちらです。
ご覧いただける通り、どちらもグラフが上向き始めたのが2012年辺りからです。
（トレンド以前も当然 User Interface などの概念は存在していたわけですが、専門家ではない人も含む世界の注目の量の増加がGoogleトレンドから読み取れると思います。）
つまり、2010年代前半から 「スマホのアプリサービスでビジネスをする」ことが浸透し、インターフェースの磨き込みや体験設計が現実的な課題になってきました。
そうなると何が起きるのか。
ここでWebの話に戻ってきますが、つまり、このUI/UXの関心の高さが自然とWebアプリケーションにも適用されるわけです。
「ネイティブアプリのようにページを跨いでもサクサクと動いて、使いやすいアプリケーションをWebで実装するには？」
これが2012年辺りのWebアプリケーションで注目され始めた非常に重要な課題の一つです。ネイティブアプリに比べて、1作業ごとにページ遷移してリクエストを待つWebページというのはどうにも動きが旧式だったのです。
この問題を解決する方法として上がったのが、「ブラウザ上でもっとリッチに実装すればいいんじゃね？」という発想で、それが Single Page Applicaion のトレンドを生み出しました。
上向き始めたのは2011年後半からですね。
そしてWeb上でSPAの実装をしようとすると、どう考えても避けては通れないのがJavaScriptという言語です。
リッチな体験をWebで実現するため、2012年ごろからJSニーズが世界的に膨れ上がることになります。
JSで実現したい様々なコト
ここで言うJSニーズというのは、
- JSでより複雑で大規模な実装がしたい
- JSでも他の言語のようなリッチな開発体験（モジュール化、パッケージ管理、ビルドシステム、IDE、etc...）を実現したい
- JSを様々な別の用途に使いたい
などです。
ここでjQueryのトレンドを見てみましょう。
jQueryのトレンドは、2013年を最後に右肩下がりになっています。
それまでフロントで主流だったjQueryが、2012年ごろを皮切りに膨れ上がったJSニーズに応えられなかったという歴史がよく見て取れます。
また、「Web技術でネイティブアプリを作ろう」という動きも、この頃にブーストされたJSニーズの一つでしょう。
有名どころで歴史が長いのはTitaniumでしょうか。トレンドの始まりは2009年と古く、2013年を境にトレンドが終わります。
Cordova のトレンドは 2012年に始まります。まさにJSニーズ拡大の最中ですね。
続いてIonicが2014年に登場します。
（矢印が2012年の4月）
このような様々な複雑な実装に対するニーズから、Nodeの人気に拍車がかかったことは想像に難くないと思います。
ECMAScriptに正式にモジュールの仕組みが入ったのは2015年のES6からです。生のJavaScriptにはパッケージ管理はおろか長らくモジュールの仕組みさえ無かったのです。
それまではCommonJSという非公式の規格が使用されており、2009年にリリースされたNodeもCommonJSを採用していました。2012年ごろに、現実的にJSでモダンな開発をするためにはNodeというプラットフォームが最適だったわけです。
冒頭でC10K問題について触れましたが、Nodeがここまでフロントエンドで存在感を持つに至ったのはパフォーマンスの観点だけでなく、 JavaScriptにモダンな開発体験を導入する上で結果的に最も都合が良かったという側面も非常に大きいと考えています。
これまでNodeを触ってきた人ならよくご存知だと思いますが、Nodeの歴史はビルドツール、バンドラー、タスクランナーなどのメタ的にJSコードを操作するツールたちと切っても切り離せません。
Browserify（Nodeのコードをブラウザで動くJSコードにバンドルするツール）なんかはまさに名前からしてその象徴と言えますね。ブラウザでリッチなアプリケーションを実装するためのツールとしての側面があったのですね。
JSを拡張するという選択肢
そんな背景があるので、JSのエコシステムには「別の言語をコンパイルしてJSを生成する」という仕組みがかなり多いです。他の言語にもそういったツールはありますが、JSは特に多いです。元々そういうことをたくさんやっていたので、受け入れられやすいっていうのがあるんでしょうね。
一時期はそうした言語のことをAltJSなんて呼んでいました。Rails人気ゆえにRuby人気が高かった2010年代前半にはCoffeeScriptというRubyライクなAltJSがあったりしました。懐かしい...
これも2011年ごろから急激に伸び、2012年がピークだったようです。
そしてAltJSの大本命が、みなさんお馴染み、TypeScriptです。
TypeScript で開発がしたい！
TSは2012年に公開されました。
このトレンドを見てもそうですが、自分の体感でもTSは突如爆発的に流行った感じではありませんでした。
今では大規模なWebフロントの開発を型なしでやるなんて考えられませんが、当時はRuby人気が高かったこともあり、アプリケーション実装における静的型付け言語に対する意見は割れていたという印象です。
なぜRubyは大規模開発でも型なしでやれているのかという点については、Railsの面倒見が良すぎるからというのが個人的な感想です。ドメインのコードはもちろんありつつ、Railsのルールに則って書く箇所が非常に多いので、APIサーバの開発においては型がなくて困った覚えがあまりありません。
あとはそもそも「Ruby で書くから Rails を使う」ではなく、「Rails を使いたいから Ruby を書く」という順序になるケースも多かったので、他の言語と比較してあえて型なしを選んでいたわけではないことも多かったでしょう。
一方で、NodeエコシステムにはNextがここまでの人気になるまでに、デファクトと言えるWebアプリケーションの包括的なフレームワークは存在しませんでした。
そもそもNodeでは薄いライブラリを作る思想が強かったので、Railsのように丸っと全てを責任持ちますみたいな思想のフレームワークが出づらかったというのはあると思います。
また、初期のRailsが担っていたような、SPA以前のWebアプリケーションにおいてはJSでのフロントの実装というのはおまけ程度で、ERB（Embedded Ruby）によるサーバサイドでのHTML生成がメインでした。
そうなると、Webアプリケーションのコードのうちほとんどの重要な部分はサーバサイドのRubyで完結していたわけですが、SPA以降のモダンな開発になるとそうはいかず、サーバもフロントも同等に大規模な実装が必要になります。（CSSはSPA以前でもいずれにせよ必要でしたが）
それら全てを一つのフレームワークに収めるのがそもそも難しかったというのもあると思います。
なので、TypeScript を後押しするような確固たる存在（RubyにおけるRailsのような）というのは案外無かったのかなと思います。
そんなこんなで浸透は徐々にでしたが、今ではTypeScript無しで開発はしたくない！と考えている人がマジョリティだと思います。
（TypeScript をなぜ使いたいのかは深堀りすると脱線になるので割愛します）
がしかし、この開発環境の話は後でも触れますが、TypeScript での開発環境を整えるのも割と一苦労あったんですよね。
これは2019年に公開した記事ですが、まさに「tsconfig.json 全然分からない、俺たちは雰囲気で TypeScript を設定している」という気分になって書いた記事です。
この記事は未完ながらもありがたくも多くの方に見ていただいており、TypeScriptの設定項目のややこしさを感じている人が多いことを実感します。
今ではほとんどの主要なパッケージが TypeScript をサポートするようになりましたが、そうなる以前は「このパッケージ使いたいけど TypeScript と一緒に使おうとするとビルドがなんか上手く通らん...」みたいなことが起きたりして、それなりに大変な時期もありました。
それゆえ、徐々にフロントエンドでの技術選定は「TypeScriptでスムーズに開発できるか？」という観点が重要になってきます。
静的サイトに対する関心度の向上＝Webフロントエンドというジャンルの盛り上がり
トレンドで見て、SPAの盛り上がりは2015年辺りにピークに達するわけですが、そうしてSPAが盛り上がってくると、がっつりサーバサイドで組み上げていたRailsと対照的に、静的サイト（サーバはHTMLを返すだけ）に対する関心度が上がっていきます。
初期、静的サイトのホスティングサービスとして生まれたNetlifyがリリースされたのは2014年です。
静的サイト＝SPAというわけではありませんが、この頃からWebアプリケーションを作る人たちの間で、 「RailsはAPIサーバに徹して、フロントは別で作ろう」という動きが生まれました。
APIモード（Railsを、JSONを返すAPIサーバとして使うモード）が含まれたRails5が出たのが2016年で、この頃のエンジニアニーズを反映しているわけです。
フロントを別で作ろうとすると、じゃあフロントのコードはどこで書き、どこにホスティングするんだ？という問題が出てきます。もちろんRailsサーバから返しても良いわけですが...
Railsとフロントエンドの分離
APIモードが出る前から、RailsのフロントでもNodeを使おうという試みがありました。Railsのレポジトリの中に、package.jsonが含まれるようになったのです。 がしかし、これが控えめに言ってもかなり使いづらかった。
元々のRailsのassets（静的コンテンツ）の仕組みがある中にNodeによるフロント開発が入るので、普通にやってたら動くのにRails環境だと動かないみたいなことが起きたりして非常にしんどい。
その苦悩の記事をここにバイネームで貼るのもどうかなあと思うので、「rails webpacker つらい」などでググってみてください（webpack ではなく webpacker です、誤字ではありません）。片鱗を味わえると思います。
（この辺主観が強くてごめんなさい。僕はWebアプリケーション開発にRailsから入った人間なのでRailsは大好きですし、Webアプリケーションを世界的に背負ってきたフレームワークとしてのリスペクトがあります。）
それならもうフロントはレポジトリ分けて全く別で作って良くない？というのがコミュニティの結論となります。
つまり、この2015年辺りで 「Webアプリケーションのフロントエンドは何を使ってどう作れば良いのか？」というのがWebエンジニアの大きな課題となりました。
いわゆる静的サイトジェネレーターが盛り上がったのは2012年辺りからで、まさにJSニーズの拡大と相関があります。
静的サイトのホスティングサービスも注目され、2014年のNetlifyに続き、2015年辺りに、ゼロコンフィグで静的サイトを一瞬でホスティングできるZEITのnowなども登場しました。そう、いまやお馴染みのVercelの前身です。
こうして徐々にWebのフロントがサーバの処理と分離され、Webアプリケーションという括りではなく、「Webフロントエンド」というジャンルも確立されていくことになります。
Nextの登場、React と共に成長へ
そんな中で、Reactを使ってフロントエンド開発が簡単にできるようになるフレームワーク、Next.jsが登場します。2016年のことでした。
Nextは静的サイトジェネレータ、あるいはSSRを簡単にSPAに導入できるツールとして注目されたわけですが、 まさに上述の、「フロントエンド、何を使ってどう作れば良いのか問題」に対する一つの答えだったわけですね。
当時はそもそもUIの実装に主要なライブラリのうち（React, Vue, Angular...）どれを使うかさえかなり意見が分かれていましたが、TypeScript と相性が良く、仮想DOMや宣言型のプログラミングがコミュニティに受け入れられ、徐々にReactが地位を上げていきます。
React の地位向上とともに、活発にアップデートされるNextも徐々に注目されるようになりました。
Nextはその後どんどん盛り上がっていきましたが、当時は今ほどのデファクト感はまだありません。僕ががっつり業務でNextを使ったのは2019年ごろでバージョンは8でしたが、その時期になってもまだ安定しているとは言えず、2019年半ばに出たNext9で、やっとNextは商用でも安心して使える感じになったね、という印象でした。個人的にはJSでいうES6の登場が、Next9に相当します。
そこからは鰻登りという感じで、2020年台に入るとフロントエンドにおけるNextの存在感は非常に大きくなっていました。
僕が前回の記事を書いたのも2020年です。
課題、解決への道
ここまでで、スマホアプリの浸透によってアプリサービスビジネスが加速し、それに伴ってWebでもリッチなアプリケーションを作るためにJSニーズが拡大したという話を書きました。
様々な実際のトレンドなどから、2012年という年（とその前後の数年）がアプリケーション史にとって非常に大きな転換点であったことが分かり、非常に興味深いです。
さて、JSニーズの拡大とNextの登場は分かりましたが、それではC10K問題やリッチなフロント開発という課題は解決したのでしょうか？
クラウドビジネスの成功により、アプリケーションとインフラは完全分離の時代へ
最近、Webアプリケーションの運用においてプロセス管理って自分でやらなくなりましたよね。
（これにはかなり諸説ある気がするのでちょっと控えめに言っておきますが...）
Dockerは2013年にリリースされました。
コンテナ技術をメインストリームに押し上げた立役者だったと思いますが、 やはりDockerとコンテナオーケストレーション技術の浸透によって、多くのアプリケーション開発者にとってのC10K問題は解決したと言っても過言ではないと思います（アプリケーション開発者にとっての、というのが重要です。インフラを支えるエンジニアの方々のおかげでアプリケーションが成り立っています。無人で神様が運用しているわけではありません。インフラおよびクラウドサービスを支えている方々に多大な感謝です）。
（規模感によっても状況は変わるかと思います。クラウドサービスではなく自前でのインフラ管理に妥当性が出るような環境では、全く話が違ってくると思います。とは言え、そういった規模の場合はアプリケーションの開発とインフラの管理は全く別のチームが行うことになると思いますが）
僕が2016〜2017年ごろに縦型動画のQ&Aサービスのバックエンドを構築した時、まだ僕はDocker（およびコンテナ技術）を理解していませんでした。
AWSのVPC内にEC2とRDSを立てて、EC2の中でUnicornでRailsを動かし、nginxをリバースプロキシにしてリクエストを受け付ける...ということを自前でやっていました。
UnicornとNginxのプロセスが今どうなっているか、ということを運用中は常に気にしていました。
（ちなみにそのサービスは全く鳴かず飛ばずだったので運用と言えるほどの運用はしていません🤣）
当時のRailsの開発者にとってはその辺りは当然のことでしたが、今ではアプリケーションの開発者は、適切なコンテナを作ってそれをクラウドのホスティングサービスにデプロイして運用は任せる、というケースが主流になってきました。
当時もHeorkuなどのPaaSを使うと似たようなことができたわけですが、やはり今のフルマネージドのコンテナ運用のサービスほどはインフラとアプリケーションの作業の分離をできなかったので、開発体験は全く別物です。
スケーラビリティをクラウドサービスに一任することによって、Webアプリケーションの開発はよりアプリケーションレイヤーの課題に注力できるようになりました。
2010年代後半はフロントエンドカオスの時代
さて、話はまたフロントエンドに戻ってきますが、2010年代（特に後半）のフロントエンドというのは端的に言ってカオスでした。
C10K問題は上述のような解決に向かいましたが、一方で 「リッチなWebアプリケーションを開発するには？」という課題は、ブラウザ上のJavaScriptという環境のもとでは非常に難易度が高かったのです。
様々なライブラリが矢継ぎ早に登場しては消え、一体僕たちは何を使って何をすれば良いんだ...！？ベストプラクティスはいつになったら生まれるんだ！？という混乱の時代です。
こうしたカオスを感じ取れる2016年の有名な記事がこちらです。
原文：
翻訳:
実態は何も変わらない
さて、久しぶりにこの記事を読んで恐ろしいことを思ったんですが...
今も全然変わってねえ...
途中まで久々に読むな〜とワクワクしていたんですが、後半になるにつれて全然笑えねーじゃん！と思いました。
僕たち、今だにWebpackやBabel（ないしは同じ立ち位置のツール）でJS（TS）をどうこうしてるんですよ。
結局のところ、ブラウザのJavaScript自体が変わらない限りはここから逃れることは出来ないんですね。
救いがあるとすれば、それはNext（など）がこれらを代わりにやってくれているということだけです。
Next以前
なぜ2010年代がカオスだったかと言えば、このNodeやTypeScriptのコンパイル周りの色々を全員のエンジニアが各自自前でやる必要があったからです。 それぞれに流派があり、どのツールの方が良いだのこっちが次のデファクトだの...
加えて、ベストプラクティスが定まっていなかったのでGulpなどのタスクランナーを繋ぐ手法も盛り上がっていたり、アプリケーションレイヤーのライブラリ（Angular vs Vue vs Reactなど...）も乱立していたり、ブラウザの対応状況的にES5以前の様々なレガシーが捨てきれなかったり...
Web を扱う上でレガシーへの対応は本当に頭を悩ませた問題でしたが、これに関して自分の中でかなり印象的だったのは、LIGさんがIE対応をやめると宣言した日です。
この記事の公開は2019年11月です。世間的に、IEはもう本当に切ろうという流れになったのが2010年代の本当に終わり頃だったということで、つまり逆に言えば、それまではずっとIEのことを考えていたということなんですよね。
Next後
そんな感じだったので、ネット上でも「Webフロントエンド、流れが速すぎてついていけない」というような声がたくさん上がっていました。2010年代後半のWebフロント領域では鉄板のネタでした。
それが今は、あんまりそういう声は聞こえなくなってきました。先ほどの逆ですが、ある程度やっとベストプラクティスが定まってきて、IEは切れたし、ECMAScriptにもそこまで大きな変化が出てこなくなり...
そして、今の僕らにはNextがあります。
Nextがゲームチェンジャーとしてフロントエンドの開発環境をも牽引し、（エコシステムの成熟という時代の流れもあり）Nextの肩に乗る限り、あまり細かいことを考えなくても良くなったのです。
ついにWebフロントエンドはビルドに悩まされるカオスの時代を抜けることになります。 最近はビルドどうすれば良いの？という話題はWebフロントの中心ではなくなりました。
Next が出る前に、混乱の時期を経て Webpack がデファクトの立ち位置になりましたが、結局 Webpack も設定ファイルを頑張って書く必要があって、それ自体が「Webpack筋」とか言ってスキルだとされた時代がありました。
しかしね、JSのコンパイルなんてのはね、はっきり言って全然面白くないわけです。素晴らしいアプリケーションを作りたいと思ってレポジトリを作ったら、何故かWebpackの設定ファイルから頑張らなきゃいけないなんて...そんなことはめちゃめちゃやりたくないw
作りたいのは素晴らしいアプリケーションであって、素晴らしいJSビルドタスクフローではない...！
「Webpack筋」とか「ウェブパッ筋」でググってみてください。当時の様子が垣間見える記述が出てきて非常に懐かしいです😇
Next も 8 とかの時代は TypeScript が標準でサポートされていなかったりとしんどい時期がありましたが、2019年にリリースされた 9 以降は TypeScript も標準でサポートされ、ビルド環境がかなり安定してきました。next dev とか叩くだけで簡単にアプリケーション開発を始められるのです。
最近では eslint の設定ファイルを書きたくなさすぎましたが、Next に lint も標準搭載されましたね。
つまり、Webエンジニアの「一体何を使って開発すればいいんだ...！？」「JSのコンパイルフロー、ダルすぎる...！」という課題を、なんだかんだで解決してきたのが Next だったんですね。
（Nextの主目的は開発環境を整えることではないので、「なんだかんだ」結果的に、です。他の様々なツールが「これが最後のJS開発環境である」と自負して登場してきたことでしょう。結果として、WebpackやBabelをラップするNextが主流になりました。（今はNextの中身も色々変わっていますが））
少なくとも、2010年代後半から2020年代初頭にかけて、Nextほど受け入れられた開発環境は他に無いと思います。
そして、React の浸透と成長によって、UIの実装に関してもだいぶ落ち着きが見えてきています。
もちろん課題が無いわけではありません。状態管理をどうするか、非同期処理をどうするか、そういった課題はありますが、2010年代のカオスに比べれば取り立てて問題がある状況ではありません。
今となっては状態管理もある程度みんな小慣れてきて、React には Suspense も正式に入りました。一定のベストプラクティスや方針が生まれてきているので、長期的なスパンで見れば収束に向かっていると感じています。
つまり、C10K問題に続き、リッチなフロント開発という課題もまた、基本的には解決されてきていると言って良いでしょう。
当然、時代の要請が変わるごとに新しい要件が生まれるので、この落ち着きがいつまで続くのかは分かりませんが。
Webアプリケーションフレームワークが直面してきた2方向の課題
さて、やっと話が現代に追いついてきました。
ここまで見ていく中で、Webアプリケーションのフレームワークが直面してきた課題というのは、ユーザー起因のものと開発者起因のものという2種類に分けられるということも分かってきました。
ユーザー起因というのはまさに2012年ごろから生まれた「Webでリッチなアプリケーションを作らねば」というメインの課題だったり、Nextが非常に注力している様々なパフォーマンスの課題だったりを指しています。
開発者起因というのがこの記事でメインに取り上げている内容で、つまりはDX（Developer Experience）に関する課題です。
これらの課題への対応は、どちらか一方に偏ることが許されないというのが現実です。
ユーザー起因の課題は本質的に注力するべきなのは当然のこと、まだ人間がプログラミングをしている以上、開発者によるコードの管理コストは現実的には無視できないんですね。
特にJS/TSにおいては非常に重要です。
そして、直近のフロントエンドにおいて、この両立をうまくやれているのがNextだったということが、これまでの歴史から感じ取れるかと思います。
Next に対する認識の変化
さて、時はかなり最近まで辿り着きました。
2023年10月31日にこんな記事が公開されました。
著者：
Kent C. Dodds は世界的に有名な講演者、教師、トレーナーであり、数百もの人気のある npm パッケージのメンテナおよびコントリビュータとしてオープンソース コミュニティに積極的に参加しています。彼はEpicReact.DevとTestingJavaScript.comの作成者です。彼は、egghead.ioとFrontend Mastersのインストラクターです。彼は Google デベロッパー エキスパートでもあります。
React や Remix の元デベロッパーでもあり、NextではなくRemixを使った方が良いという主張が書かれています。
実はこちらの記事に、なんとなく見てみぬふりをしてきたNextに覚える違和感が良い感じに言語化されています。
超雑に要約するなら、「NextはWeb標準から外れている、営利企業Vercel（の運営構造）が信用できない」という感じでしょうか。
（Too much magic などはちょっとそれとズレるかもしれませんが、「標準を使わずに自前で魔法を実装する」という開発スタイルから来る結果が Too much magic だと思うので、結局のところ「Vercelが独自の仕様でロックインを狙っている」という疑念が大元であると思います）
この要約だけだと語弊がありまくるので詳しくはぜひ実際の記事を読んでみてください。
さらに、この記事に対するアンサーがVercelの中の人から公開されています。
（双方の記事で、お互いに交友とリスペクトがあることを強調してる）
要約すると、「そういった疑念は正しくなく、Vercelは（営利のみの追求ではなく）公正に技術に向き合っている。またNextはリリースが2016年と（フロントエンドの世界においては）かなり古く、その当時は独自実装せざるを得なかった実装も徐々にアップデートで標準に寄せていっている」といった感じ。
これまた個人的な感想ですが、Vercel的にもこういった疑念やNextにおける問題の存在、そしてそれを指摘されることも重々承知の上で色々とことを進めていると思います。
Webはネイティブアプリと違って一企業に依存しない世界的な標準が尊重される世界なのは間違いなく、Remixの「Remixで身に付くスキルはWebのどこに行っても通用する、なぜなら標準だから」っていう主張はすごく魅力的ですよね。
個人的にも（ネイティブアプリを少し書いていた時期も経て）やっぱりWebが好きなのはその「どこにも属していない、依存が少なく自由である感覚」が好きだからだと思います。
この感覚は恐らく多かれ少なかれほとんどのWeb開発者の中にあって、だからこそ "Too much magic" で裏で何をしているか分からない、Vercelというホスティングプラットフォームじゃないと動かない、みたいな印象というのは極端に言えばかなり"悪"に近いと認識されてもおかしくないでしょう。
（そのどこにも所属しない自由さゆえにJSは長らくカオスだったわけですが😇）
その個人的な感覚の表現方法はさておいたとしても、上記の記事を読めば、なるべくWeb標準に寄せるというのがコミュニティに対するポジティブな姿勢であることは読み取れます。
Vercel的にも当然のことながら開発者コミュニティに受け入れられるということは超絶重要なことですね。
自身を「KubernetesとGoogle Kubernetes Engine」という関係に例えているところからも、Vercelがなんとかこのイメージから脱却し、Nextというフレームワークをより確固たるデファクトにしたいという意思が感じられます。
（Kubernetesは実質コンテナ技術の運用ツールのデファクトです。）
すごい Next、ちょっとすごすぎるかも...
さて、近年の Next に対する評価としてやはりこの話題についても言及しなくてはいけません。
Next、凄すぎて、複雑すぎて、だんだんついていけなくなってきた...というやつです。
プリレンダリング周りのサーバ側の機能に加え、Server Actions やら、Server Components やら、なんかもう最近なんでもありだね！？
個人的には Server Actions の印象がやべーです。あんたまたユニバーサルJSやろうとしてんのかい！？
Server Actions に関しては別に使わなければ良いですが、そういうところにも注力するのね〜という見え方にはなります。
あと自分の周りでも聞こえてくるのは、自動で行われるキャッシュがもはや何をしているのか分からなくて危険という問題。新機能を導入しなくても、勝手に色々やってくれちゃうことが多すぎると。
それに、RSC前提の App Router になったけど、ぶっちゃけRSCで嬉しい思いをすることがほとんど無い。RSC使ってハッピーになった現場ってどれくらいあるの？
などなど...
Next は機能が増えて複雑になった結果、「ほとんどのプロジェクトにはそこまで必要ないのでは...」という域に達してしまったように見えます。
これが冒頭で触れた「Next が人を選ぶようになってきた」という表現の所以です。
こんにちは、Vite
でもねえ、Next を使わないとなると、それはまたTSのコンパイル環境とかを自前で用意しろってことですか？
Next 以前のJS環境に戻りたくなんか...
え？Vite？
いや、僕 Vue は使ってないけど...
え、Vue は関係ないの？
npm run dev 叩くだけで開発サーバが立ち上がって、HMRもできて、当然標準でTypeScriptをサポート、本番ビルドもできる...？
...
あれ？Nextってなんで必要なんだっけ？
開発環境さえ整えば...
ということで、すっごく雑に表現すると、Nextから開発環境だけ切り出した感じのものが Vite となっておりまして、これがものすごく便利なんですね...
元々 Vue のためのツールだと僕は認識していたんですが、気づいたらフロントエンド全般を対象としたビルドツールに変わっていました。
結構多くのプロジェクトにおいて、開発環境さえ整えられれば、Nextの最新の機能のほとんどは無くて良いんじゃないでしょうか
Vite は初リリースが2020年らしいですが、直近1,2年でかなり人気が急増している気がします。
トピックとしての Vite が増え始めたのは 2022年ごろからのようです。
（vite js などのキーワードで見ても、やはり2022年辺りから伸びています。）
これもまた、「モダンな万全の開発環境で開発したいが Next は重すぎる」というエンジニアニーズに応えられているがゆえの伸びだと思います。
最後に
ということで、Next に対する盲目的な魔法が徐々に解け始めている感じのするフロントエンド環境の現在までを見てきました。
今まで見てきたように、NextがWebフロントに与えた影響というのは本当に大きかったです。
React の発展にも貢献してますし、Vercelの台頭以降、Vercelと似たようなビジネスモデル（OSSのツールと有料ホスティングという組み合わせ）の技術系サービスはかなり増えた印象があります。
この記事は少し偏った角度からの考察でしたが、結局のところ絶対的な物差しは存在せず、要件次第で選ぶツールは変わるということになります。
自分や周りに関しても Next がだめだから離脱したとかではなく、シンプルに要件に合う合わないで判断した結果今は使っていないというだけです。
Next を使うか使わないか検討する際は、ぜひ「Vite でシンプルに作っちゃう？」という選択肢もぜひ検討されてください。
僕たちが愛してやまない、"何者にも縛られない自由の香り"を感じることができるでしょう😈
参考