
你好,我是 Watanabe Jin(@Sicut_study)。
今天,我們習以為常使用的 React 框架「Next.js」,已被 Netflix、Uber、OpenAI 等世界各地的巨型企業採用,許多日常使用的服務也都是以 Next.js 建構而成。
在前一篇 React 歷史的文章中,我介紹了 React 如何克服早期的激烈批評,並一步步攀上網頁開發的「王者」之位。
然而,React 的勝利,也意味著新問題的開始。
這次要介紹的是:為了解決 React 所面臨的課題而誕生、在現代前端開發中成為事實上的標準(de facto standard),卻又正面臨新試煉的 Next.js 歷史。
我們也很用心製作了影片,希望大家一定要看看看!!
↓↓↓
<a href="">1. React 遺留下來的課題——「SPA 的三重苦」</a>
<a href="">2. 一位駭客的挑戰</a>
<a href="">3. Next.js 的「6 大原則」與靜默革命</a>
<a href="">4. ISR 的魔法與 Gatsby 之戰</a>
<a href="">5. Vercel 時代的光與影——Telemetry 問題</a>
<a href="">6. App Router 的混亂與 RSC 的脆弱性</a>
<a href="">7. 為什麼開發者離不開 Next.js</a>
<a href="">8. 總結</a>
2014 年到 2016 年之間,Facebook、Instagram、Airbnb 等許多企業開始採用 React。當時很多開發者都使用 Create React App,用一行指令就能輕鬆建立 React 應用程式。
但 Create React App 有明確的限制。
那就是它基本上只能建立 SPA(單頁應用程式)。
SPA 對開發者與使用者都帶來了「三大問題」
為了自己打造路由、資料擷取、伺服器端渲染(SSR),在 webpack 設定地獄中苦撐的某位開發者忍不住大喊:
「要用 React,還得學這麼多東西嗎?」
業界開始尋找一種「保留 React 優點,同時解決這些問題的框架」。
挑戰這個問題的人,是出生於阿根廷布宜諾斯艾利斯近郊的年輕程式設計師 Guillermo Rauch(吉列爾莫・勞赫)。

他不是一般的小孩,從小就沉迷於程式設計,十幾歲時就在開源世界闖出名號。當許多人正是進入大學的年紀時,他已經共同創立了 LearnBoost 與 Cloudup,並擔任 CTO,可說是天才級人物。
吉列爾莫堅信:「網路可以更好,也可以更簡單。」
在 WebSocket 還不普及的年代,他創造了廣受歡迎的即時通訊函式庫 Socket.IO。
2015 年,吉列爾莫成立了一家新公司。
名字叫做「Zeit」(德文,意為「時間」)
第一個產品是可用一條指令部署應用程式的革新性部署工具「Now」。
但他的野心更大,他是這樣想的:
「React 很棒,但太複雜了。來做一個全端 React 框架吧,做成不用設定、開箱即用的版本。」
團隊成員覺得「風險很大」、「真的有需求嗎?」;但他早已有明確的願景。
吉列爾莫與他的團隊,為這個新框架定下了以下設計方向:
(雖然不是正式名稱,但這些很能代表設計理念,因此被稱為「6 大原則」)
2016 年 10 月 25 日。
沒有盛大的發表活動,也沒有新聞稿,Next.js 以一個小小的 GitHub repository 形式公開了。
和 Create React App 不同,Next.js 從一開始就內建路由,只要放入檔案就會自動產生路由,也支援 SSR。
看到這一點的開發者立刻有了反應,並開始口耳相傳:「就是這個,我們一直在等的就是這個。」
Next.js 真正的創新出現在 2020 年。
在 Next.js 9.3 中引入了新的資料取得 API,接著在 9.4~9.5 登場的是 ISR(Incremental Static Regeneration:增量式靜態再生)。

傳統靜態網站是「很快,但每次都要重新建置全部頁面」,動態網站則是「永遠最新,但速度較慢」;ISR 則兼顧兩者優點,提供近乎魔法般的能力:先在建置時產生靜態頁面,當頁面被存取時,只對個別頁面在背景中重新生成。
這對部落格與電商網站而言,是革命性的。
同時期,與 Jamstack 寵兒 Gatsby 的霸權之爭也在進行。
Gatsby 專注於靜態網站生成,因此非常快速,但它以 GraphQL 為前提所帶來的複雜性,以及大型網站建置時間動輒數十分鐘到一小時的問題,也逐漸浮現。
追求實際營運穩定性的大型服務,如 Twitch、TikTok、Hulu,開始陸續轉向 Next.js。
而在 2020 年,Zeit 也改名為 Vercel,進一步強化了自己作為 Next.js 專屬平台的形象。
隨著 Vercel 登場,邊緣功能、圖片自動最佳化、與 CDN 整合等能力讓 Next.js 建立起「完美生態系」。
而決定性的事件,是 React 官方文件改寫為「如果要使用 React,建議搭配 Next.js 這類框架」。

「React 要上正式環境=就用 Next.js」成為了事實上的標準。
然而,在勝利背後,第一道裂痕也開始浮現。
Next.js 預設啟用了使用統計等 Telemetry(匿名資料傳送)。
Vercel 的說法是「為了改善框架」,但因為這些資料是在沒有明確同意(非 opt-in)的情況下傳送,社群批評聲浪隨即湧現。
「Next.js 到底真的是為社群而生的框架,還是 Vercel 的工具?」
雖然是開源專案,但路線圖由 Vercel 決定、新功能也由 Vercel 設計,而且這些功能在 Vercel 平台上才能發揮最佳效果;開發者開始對這種結構產生疑問。
2022 年 10 月,Next.js 13 發表,導入了使用新技術 React Server Components(RSC)的全新路由系統 App Router。
理論上非常革命性,但現實卻相當嚴峻。
開發者紛紛抱怨:
熱重載(Fast Refresh)不穩定,而且等待時間很長。
建置時間變長。
錯誤訊息過於艱澀,根本看不出原因。
有位開發者將專案遷移到另一個框架(Remix)後,回報比起 Next.js 時代大幅減少了依賴與 bundle 大小,並形容這個過程是:
「這不是最佳化,這是在挖掘考古遺跡。」
此外,到了 2025 年,還接連發現了重大漏洞。
CVE-2025-29927 (CVSS 9.1)(2025 年 3 月):可繞過 Next.js Middleware 的授權邏輯,可能導致未經授權存取受保護頁面。
CVE-2025-55182 (CVSS 10.0)(2025 年 12 月):React Server Components 中的遠端程式碼執行漏洞。
來自支撐 React 生態系的知名開發者們,也發出了嚴厲的聲音。
既然有這麼多不滿,為什麼開發者不改用 Remix、Astro、SvelteKit 這些更輕量、也更令人滿意的框架呢?
原因在於生態系的重力(沒有廠商綁定的市場綁定)。
UI 函式庫與部署工具,往往都先以能在 Next.js 上運作為目標,甚至是專為 Next.js 而設計。
學習、求職、徵才時,「有 Next.js 經驗」也更有利,於是學習者持續增加。
要遷移到其他框架,就需要團隊重新訓練、重寫既有程式碼、說服利害關係人,付出極大的成本與「政治判斷」。
開發者之所以持續使用 Next.js,不是因為「它絕對是最好的」,
而是因為「離開它的成本,還沒大到超過留下來的痛苦」。
這就是所謂的 「慣性定律」。
從 Next.js 的歷史,我們能學到什麼呢?
你覺得如何呢?
這個原本以「救世主」之姿誕生的 Next.js,如今卻被視為「麻煩製造者」的故事。
這不是在批判 Next.js,而是在談論技術選擇所伴隨的責任。
技術演進從來沒有完美解答。
要打造更美好的網路未來,最終還是取決於我們這些開發者自己的選擇。
你覺得如何呢?
因為 AI 熱潮的關係,Next.js 似乎也變得更加不得不被選擇。
未來前端歷史會如何改變?其他框架會加入霸權之爭嗎?
真的很令人期待。
我有上傳更詳細解說的影片,有興趣的話歡迎看看!
程式設計教練 JISOU 正在招募新成員。
想在日本第一的輸出型社群中提升職涯嗎?
有興趣的人,歡迎直接到官網申請諮詢!
▼▼▼
原文出處:https://qiita.com/Sicut_study/items/8fa7302bbb5bc1c897bf