web前端開發未來發展的趨勢（2023年前端十大Web）

2023-04-30 18:24:25 1

作者 | Robin Wiruch

譯者 | 核子可樂

策劃 | 丁曉昀

雖然就個人觀點，我覺得 Web 開發的前景已經好幾年沒什麼進展（2016 年至 2021 年），但在剛剛過去的 2022 年中確實又猛竄了一波。在本文中，我想跟大家聊聊自己看到的最新 Web 開發趨勢。相信這波浪潮會繼續激發 Web 開發者的關注，也讓我對萬象更新的 2023 年更具期待。閒言少敘，我們馬上進入正題。

單頁應用程式（SPA）及各類相關框架（包括 React.js、Vue.js、Svelte.js 等）或多或少都經歷過一定的炒作周期，也用多年閱歷證明了自身強大的生命力。但隨著以這些解決方案為基礎的元框架的快速興起，可以看到應用程式正在明顯從客戶端渲染（CSR）轉向伺服器端渲染（SSR）。如今，無論你使用哪一種 JavaScript 框架，總能看到 SSR 的影子。

其中最具人氣的 Next.js 元框架就以 React.js 為基礎。React 核心開發者 Andrew Clark 將 2022 年發布的新版本稱為「真正的 React 18」，因為其中包含 React 團隊為底層庫基礎構建塊構建的所有 battery（例如 Suspense、流式 SSR 等）。Vercel（Next.js 背後的公司）也與 React.js 核心團隊緊密合作，共同打造出色的開發者體驗。

雖然不少開發者都對 Next.js 和 React.js 之間過於「親密」的關係頗有微詞，但 React.js 並非不可替代。最近剛剛被 Shopify 收購的 Remix，就採用不同方法將 React.js 轉化為元框架（例如將 Web 標準設為優先）。而且在競爭之外，兩套框架之間也有一定程度的功能融合（例如嵌套路由）。

除了現代 SSR 領域最有力的參與者、幫助眾多前端開發者順利成型為全棧開發者的 Next.js，其他一些重要框架同樣值得大家關注：SvelteKit（基於 svelte.js 構建）及其最新 1.0 版本是由 Vercel 和 SolidStart（基於 Solid.js 構建）提供支持，較 React.js 擁有更好的開發者體驗。

雖然過去的十年（2010 年至 2020 年），Web 世界一直由單頁應用程式（SPA）及其客戶端渲染模式（CSR）所主導——從 Knockout.js 到 Ember.js，再到 Angular.js、React.js 以及 Vue.js 莫不如是——但最近兩、三年，人們對使用元框架的伺服器端渲染（SSR）越來越青眼有加。從外部來看，這似乎只是歷史的又一輪循環，畢竟在多頁應用程式（MPA）中使用 SSR 和 JavaScript（例如 jQuery、MooTools、Dojo.js 等）的作法早在 2005 年到 2010 年就曾盛極一時。但這波浪潮的意義絕不只是曾經的 Java（例如 JSP）或後來的 Ruby on Rails 被納入 SSR，而在於 JavaScript 依賴性的不斷增長。幾年以來，Next.js 一直是這股變化背後的核心驅力，而 SvelteKit 等其他元框架也正在加入戰團、共同促成這一歷史性轉變。

儘管兩種模式的基本用途並不相同，但憑藉長久以來與靜態站點生成（SSG）的競爭，SSR 如今已經擁有近乎完美的性能表現（參考 Next.js 和 Gatsby.js）。在應用場景下，SSG 一般用於靜態內容（例如博客等網站），而 SSR 則用於動態內容（例如 Web 應用程式）。如果需要考慮 SEO（搜尋引擎優化），則 SSR 和 SSG 均適用。但如果需要提供高度動態的內容，或者是交付以用戶為中心的內容並涉及身份驗證，則 SSG 適用性較差（在部署前一次性構建，即靜態）；這時候最好是在 SSR（能根據伺服器上的單個數據請求按需構建）或者是最近熱度飆升的 CSR（在客戶端上按需獲取個別數據）間做選擇。

但這裡要強調，CSR、SSR 和 SSG 都不屬於新興的渲染技術。雖然 SSR 和 SSG 在前幾年迎來了一波性能優化趨勢，但實際發展的只是增量靜態再生成（ISR）和流式 SSR 等更具體的渲染技術。前者改善了 SSG 性能，允許在每頁基礎之上靜態重建整個網站。更進一步的方法還有按需 ISR，也稱按需重新驗證，可通過應用程式公開的 API 觸發重建（例如在 CMS 數據更新時觸發）。

另一方面，流式 SSR 則優化了伺服器端渲染的單線程瓶頸。普通 SSR 需要在伺服器上等待數據就緒，之後再將渲染完成的內容發送至客戶端。相比之下，流式 SSR 允許開發者將應用程式拆分成多個塊，讓各個塊逐步由伺服器並行發送至客戶端。

過去幾年間，SPA/MPA 中的 SSG 和 SSR 渲染模式由極簡單，逐步發展成如今愈發微妙的形態。而且不單是 ISR 和 SSR 流有所聯繫，部分水合（Partial Hydration，例如 React 伺服器組件）允許僅在客戶端上水合某些組件、漸進式水合可對水合順序進行細粒度控制、Island 架構（例如 Astro）面向 MPA 中的隔離應用或組件，甚至出現了以可恢復性代表水合（例如 Qwik）的另一種有效方法。

SSR 和 SSG 等渲染技術與邊緣無伺服器的普及態勢高度相關，原因是這些趨勢均受到性能驅動，目的是在瀏覽器中提供無縫的用戶體驗。從本質上講，正是為了向用戶提供更快的網站和 Web 應用程式響應速度，才最終催生出邊緣無伺服器這一技術分支。

這裡咱們還是從頭開始慢慢捋順：無伺服器，又稱無伺服器函數、無伺服器計算 （例如 AWS Lambda）或雲函數（例如 Google.Firebase Cloud Functions），多年來一直在雲計算領域佔據一席之地。雖然無伺服器並不是真正的不需要（遠程）底層伺服器，但開發者已經不必管理伺服器及其相關任務（例如基礎設施按需擴展）。相反，用戶只需要將單一功能部署為無伺服器函數，其他所有運維工作均由雲服務商承擔。

無伺服器函數的出現帶來了一大優勢：由於不需要將應用程式伺服器部署到特定一處或幾處數據中心，我們首次實現了功能在世界各地的廣泛覆蓋。因此在理由情況下，無伺服器函數能夠儘可能貼近與用戶間的距離，即最大程度降低客戶端 - 伺服器間的往返延遲，由此改善用戶體驗。也正是這種儘可能靠近用戶部署無伺服器函數的思路，創造出了邊緣計算和邊緣函數兩個術語。

眾多雲服務商（包括 Cloudflare 和 Cloudflare Workers、Vercel 及其 Edge Network、Deno 及其 Deno Deploy 等）已經在這個領域展開競爭，各自努力為最終用戶提供最佳交互時間（TTI）體驗。邊緣函數不僅能加快 SSG/SSR 內容的交付速度（因為連接最終用戶的線路更短），而且能將結果緩存到離用戶更近的位置。

但除了性能之外，邊緣計算還在成本等其他重要因素上具備優勢。例如，對於邊緣函數，客戶端與伺服器之間往來的數據中有相當一部分並不需要交由主數據中心處理。在物聯網場景中，有大量非相關數據（例如內容無任何變化的視頻記錄幀）其實沒有任何意義，直接在邊緣位置篩選即可。這就大大節約了數據傳輸與集中設施處理帶來的日常開銷。

隨著無伺服器（邊緣位置）的出現，資料庫也迎來一波復興。使用無伺服器函數，開發者很快就會遇到資料庫連接開啟過多的問題，這是因為新的邊緣設施形態導致每臺伺服器不再固定保持一條開啟連接，而是每個無伺服器函數都與資料庫一一連接。雖然連接池能夠很好解決問題，但用戶要麼需要自建，要麼由第三方服務商提供。

無伺服器資料庫領域的熱門競爭者包括 PlanetScale（MySQL）、Neon（PostgreSQL）和 Xata（PostgreSQL），它們具備資料庫分支、schema diffing 和強大的搜索 / 分析 / 洞察功能。遍布全球各地的無伺服器設施只需要提供邊緣緩存或分布式只讀資料庫，確保讓數據儘可能靠近用戶位置、最大程度降低延遲。

如果第三方服務不僅需要分發資料庫，還需要分發應用程式，Fly.io 能夠將所有內容打包至單一平臺當中。這類應用就超越了常規資料庫，進而推動新的技術變革。人們常將 Railway 視為 Heroku 的繼任者，它為平臺即服務（PaaS）帶來了部署技術堆棧所需要的一切。如果大家希望將服務鏈上移至後端即服務（BaaS），則可通過 Supabase 使用 Firebase 的開源替代方案，獲得應用程式 / 資料庫託管、身份驗證和邊緣函數等功能。

一切都始於 Ryan Dahl 在 2009 年一場會議上公布的 Node.js。最初，Node.js 的目標只是將 JavaScript 和瀏覽器拆分開來，嘗試將其運行在伺服器端。但後來，JavaScript 成為過去十年間最成功的 Web 開發驅動力。本質上，Ryan Dahl 在無需瀏覽器本體的情況下，為 Node.js 開發出了名為 V8 的 JavaScript 引擎（由 Chrome 實現）。因此，Chrome 瀏覽器和 Node.js 使用的是完全相同的 JavaScript 引擎，但二者各自有自己的 JavaScript 運行時（例如瀏覽器 API 與節點 API）來實現交互。

十年之後，Ryan Dahl 宣布 Deno 成為 Node 的繼任者，並承諾為開發人員提供一個更安全、更快捷的環境，其中還將包括瀏覽器 API、TypeScript 和一個開箱即用的標準庫。Deno 同樣運行在 V8 引擎之上，但如今的它只是眾多 JavaScript 運行時中的一種。

在邊緣函數這一競爭領域，各雲服務商也在紛紛實現自己的 JavaScript 運行時（例如 Cloudflare Workers，專門針對自家 Cloudflare 基礎設施進行了優化）。因此，Deno 的商業模式也開始向雲服務商轉型，打造出 Deno Deploy 及其即時邊緣渲染 SSR 框架（最初僅為概念驗證）Deno Fresh。此外，像 Bun（以運行在 JavaScriptCore 引擎上，卻依託於 Zig 實現而聞名）這樣的獨立解決方案，也在這場以速度為比拼要素的 JavaScript 運行時競賽中獲得了一定關注。

面對這麼多運行時選項，相信敏銳的讀者朋友肯定感受到了技術碎片化的傾向。如果協調不當，那我們又會像當年各種各樣的瀏覽器那樣疲於為 JavaScript 提供支持。但好在這次競爭的焦點在於伺服器端，而且不同雲服務商對於各種 JavaScript 運行時的關注度也大有區別。為了保持江湖地位，Deno、Vercel、Cloudflare 等利益相關方紛紛加入 WinterCG，表示願意就 JavaScript 運行時間的 API 互操作性開展合作。

過去，Monorepo 策略主要用於大型應用程式，其中各項目在單一版本控制倉庫中僅包含較小體量。這些較小的項目單元可能是獨立應用程式（例如 SPA、MPA），也可能是可復用包（例如函數、組件、服務等）。這種項目拆分再合併的作法可以追溯到 2000 年初，那時候的名稱叫共享代碼庫。

但如今的 Monorepos 不僅面向大型應用程式，同時也開始服務於小型企業和開源項目。例如，一家公司可以在 Monorepos 中包含各種包，例如共享 UI 組件、共享設計系統（例如可復用的協作設計）以及不同領域的日常實用工具函數。

這些包可以在各種應用程式中直接導入：使用所有共享包的實際應用程式（例如 app.mywebsite.com 客戶端渲染）、僅使用共享設計系統包且考慮 SEO 需求的主頁 / 產品 / 登陸頁面（例如由伺服器端渲染或靜態站點生成的 mywebsite.com），以及使用共享 UI 組件和共享設計系統包的技術文檔頁面（例如 docs.mywebsite.com）。

現已被 Vercel 收購的 Turborepo，目前就致力於在 JavaScript/TypeScript 中大肆宣傳 Monorepo 方法。Turborepo 幫助開發團隊在 Monorepo 中為所有應用程式和包創建構建管線。其最大亮點，就是能在本地機器或雲端實現跨團隊的管線內 build 緩存。

Turborepo 與 npm/yarn/pnpm 工作區（依賴項管理）和變更集（版本控制）等其他重要 Monorepo 工具相結合，共同為這部分開發生態吸引到了全球 Web 社區的目光。

Turborepo 的競爭對手包括 Nx、Rush 和 Lerna（一段時間停止維護，後被 Nx 開發商 Nrwl 所收購）。

對這波趨勢，喜歡的超喜歡、討厭的特討厭。Tailwind CSS 是實用工具優先 CSS 的典型代表。一方面，開發人員討厭它的存在令 UI 代碼顯得冗長；但另一方面，開發者又喜歡它出色的開發體驗。作為直接受眾，開發人員只需要在項目中進行一次配置，即可立即在 HTML 中使用其預定義的 CSS。

但隨著近期伺服器端渲染（SSR）的興起，這種關於實用工具優先 CSS 的愛恨割裂有望徹底結束。幾年來，像 Styled Components（SC）和 Emotion 這樣的 CSS-in-JS 解決方案，一直是現代基於組件的 Web 應用程式樣式的主導力量。然而，如果說 SSR 世界始終以性能為至高目標，那 CSS-in-JS 的存在本身就是反性能的：它會讓包更加臃腫（SC 為 12.7 kB，Emotion 為 7.9 kB），而且在插入 DOM 前的 CSS 序列化也會帶來額外的運行時開銷。

因此，我們可能會看到開發人員轉向對 SSR 更友好的解決方案，例如將實用工具優先 CSS（例如 Tailwind CSS、UnoCSS）與預定義的 UI 組件（例如 DaisyUI）配對，使用 CSS 模塊等其他同樣流行的替代方案，或者選擇零運行時 / 編譯時 CSS-in-JS 類方案（例如 vanilla-extract、linaria、astroturf、complied 等）。

從 JavaScript 到 TypeScript 的演變已經勢不可擋。在這場席捲整個 Web 開發世界的大遷移中，全棧應用的端到端類型安全無疑是一大核心驅力。這個概念的實現與通信層（API）密切相關，因為通信層需要將類型化的實體（例如 type User、type BlogPost 等）從伺服器橋接至客戶端應用程式。

在涉及客戶端 -0 伺服器通信的 Web 開發中，常見的選項是 REST 和 GraphQL。二者能與 OpenAPI for REST 和 GraphQL Code Generator for GraphQL 配合使用，為前端應用程式生成類型化的 schema 文件。

除此之外，還有名為 tRPC 的類型安全 API 後起之秀，它已經證明自己完全有能力成為 REST/GraphQL 的替代方案。如果您已經使用了前端和後端共享代碼的 TypeScript Monorepo，tRPC 允許大家將所有類型從後端導出至前端應用程式，過程中無需生成任何類型化 schema。之後，前端只須使用在後臺通過 HTTP 連接的類型化函數即可調用後端 API，實現客戶端 - 伺服器間通信。未來，全棧應用程式的總體趨勢一定會轉向這種類型安全解決方案。作為其中的典型代表，tRPC、Zod、PrismatTanStack Router 都能在應用程式邊緣提供類型安全保障。

在 React-land 中，create-react-app（CRA）曾多年佔據主導。這在當時掀起了一場小小的革命，因為初學者獲得了一個隨時可用的 React 入門項目，不再需要使用 React 配置自定義 Webpack。但過去短短一年之間，Webpack 卻迅速過時。

Vite 雖然是單頁應用程式（SPA）領域的新秀，但卻能跟所有流行框架（例如 React.js）配合構建入門項目。作為 Vue.js 締造者尤雨溪的又一力作，Vite 的定位是下一代前端工具。在引擎蓋之下，它從 esbuild 處繼承了強大的功能；而且跟其他 JavaScript 打包器相比，它是用 GO 編寫的，因此打包依賴項的速度能達到競爭對手（例如 Webpack）的 10 到 100 倍。

Vite 的生態系統是伴隨著 Vitest（Jest 的測試替代方案）等新增功能而蓬勃發展，同時 Vercel 的 Turbopack 等同類競爭方案近期也開始湧現。Turbopack 被稱為 Webpack 的繼任者，因為它是由 Webpack 的締造者 Tobias Koppers 牽頭開發完成。由於 Next.js 既是 Webpack 的現用戶，一邊又是 Turbopack 的開發商，所以預計 Next.js 和 Turbopack 在後續將成為緊密關聯的一對 Web 組合。

AI 最終會消滅開發者的工作崗位嗎？這個問題還賄答案，但 AI 驅動開發確實在 2022 年內成為了現實。隨著 GitHub Copilot 的發布，開發者們能夠在自己喜愛的各種 IDE 中與 AI 助手結對。其使用過程與常規編碼或者注釋編寫沒什麼區別，GitHub Copilot 會自動補全細節以儘量提升代碼質量。

還不止於此：OpenAI 的 ChatGPT 是一套高度通用的語言模型，而且在編程領域也有不俗表現。沒錯，ChatGPT 既能回答形式多樣的自由提問，也能生成頗為靠譜的開發成果。不少開發者不知不覺減少了對 Stack Overflow 的訪問，轉而跟 ChatGPT 討論技術問題。在多數情況下，ChatGPT 都能以搜尋引擎替代品的姿態提供非常有用的答案（雖然還稱不上完美）。相較於存在大量 SEO 垃圾、甚至跟開發毫無關聯的廣告內容，ChatGPT 的使用感受相較於傳統搜尋引擎提升了一大截。

但請注意，這種短期收益也許會帶來深遠的危害。宏觀來講，AI 創建的內容可能、甚至可以說一定會危害整個網際網路。以往手動創建的 SEO 宣傳內容已經是個大難題，未來沒人攔得住 ChatGPT 以人類無法比擬的效率自動生成更多 SEO 垃圾。如果 ChatGPT 自己在訓練中也繼續使用這些垃圾內容，後果將不堪設想。

還有一些我覺得很重要，但未被列入十大的重要趨勢。首先，Tauri 作為 Electron 的替代品開始進入 JavaScript/CSS/HTML 實現的桌面應用程式；Playwright 正成為 Cypress 的 E2E 測試替代品；Warp 與 Fig 有望成為下一代終端；CSS 容器查詢則作為 CSS 媒體查詢的響應式設計替代方案；最後，htmx 作為富 HTML 格式，能夠不藉助 JavaScript 創建出交互式用戶界面。總之，以上只是我的個人整理，感興趣的朋友不妨自行探究更多細節。

希望這次的文章能幫大家更好地了解 Web 開發生態系統的發展現狀。Web 開發無界，江湖有緣再見！

https://www.robinwieruch.de/web-development-trends/

你可以錯過Web3，但不要錯過Web5

雲原生 AI 的資源調度和 AI 工作流引擎設計分享

TypeScript 前端工程最佳實踐

複習前端：CSS

本文轉載來源：

https://www.infoq.cn/article/PoZLOO8QEf98GoDzV7Nr