在本文中，六星云課堂想跟大家聊聊最新 Web 開發(fā)趨勢。相信這波浪潮會繼續(xù)激發(fā) Web 開發(fā)者的關(guān)注，也讓我對萬象更新的 2023 年更具期待。閑言少敘，我們馬上進入正題。

（元）框架

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

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

雖然不少開發(fā)者都對 Next.js 和 React.js 之間過于“親密”的關(guān)系頗有微詞，但 React.js 并非不可替代。最近剛剛被 Shopify 收購的 Remix，就采用不同方法將 React.js 轉(zhuǎn)化為元框架（例如將 Web 標準設(shè)為優(yōu)先）。而且在競爭之外，兩套框架之間也有一定程度的功能融合（例如嵌套路由）。

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

應(yīng)用程序與渲染模式

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

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

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

另一方面，流式 SSR 則優(yōu)化了服務(wù)器端渲染的單線程瓶頸。普通 SSR 需要在服務(wù)器上等待數(shù)據(jù)就緒，之后再將渲染完成的內(nèi)容發(fā)送至客戶端。相比之下，流式 SSR 允許開發(fā)者將應(yīng)用程序拆分成多個塊，讓各個塊逐步由服務(wù)器并行發(fā)送至客戶端。

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

邊緣無服務(wù)器

SSR 和 SSG 等渲染技術(shù)與邊緣無服務(wù)器的普及態(tài)勢高度相關(guān)，原因是這些趨勢均受到性能驅(qū)動，目的是在瀏覽器中提供無縫的用戶體驗。從本質(zhì)上講，正是為了向用戶提供更快的網(wǎng)站和 Web 應(yīng)用程序響應(yīng)速度，才最終催生出邊緣無服務(wù)器這一技術(shù)分支。

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

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

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

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

數(shù)據(jù)庫復興

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

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

如果第三方服務(wù)不僅需要分發(fā)數(shù)據(jù)庫，還需要分發(fā)應(yīng)用程序，http://Fly.io?能夠?qū)⑺袃?nèi)容打包至單一平臺當中。這類應(yīng)用就超越了常規(guī)數(shù)據(jù)庫，進而推動新的技術(shù)變革。人們常將 Railway 視為 Heroku 的繼任者，它為平臺即服務(wù)（PaaS）帶來了部署技術(shù)堆棧所需要的一切。如果大家希望將服務(wù)鏈上移至后端即服務(wù)（BaaS），則可通過 Supabase 使用 Firebase 的開源替代方案，獲得應(yīng)用程序 / 數(shù)據(jù)庫托管、身份驗證和邊緣函數(shù)等功能。

JavaScript 運行時

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

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

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

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

Monorepo

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

但如今的 Monorepos 不僅面向大型應(yīng)用程序，同時也開始服務(wù)于小型企業(yè)和開源項目。例如，一家公司可以在 Monorepos 中包含各種包，例如共享 UI 組件、共享設(shè)計系統(tǒng)（例如可復用的協(xié)作設(shè)計）以及不同領(lǐng)域的日常實用工具函數(shù)。

這些包可以在各種應(yīng)用程序中直接導入：使用所有共享包的實際應(yīng)用程序（例如?http://app.mywebsite.com?客戶端渲染）、僅使用共享設(shè)計系統(tǒng)包且考慮 SEO 需求的主頁 / 產(chǎn)品 / 登陸頁面（例如由服務(wù)器端渲染或靜態(tài)站點生成的?http://mywebsite.com），以及使用共享 UI 組件和共享設(shè)計系統(tǒng)包的技術(shù)文檔頁面（例如?http://docs.mywebsite.com）。

現(xiàn)已被 Vercel 收購的 Turborepo，目前就致力于在 JavaScript/TypeScript 中大肆宣傳 Monorepo 方法。Turborepo 幫助開發(fā)團隊在 Monorepo 中為所有應(yīng)用程序和包創(chuàng)建構(gòu)建管線。其最大亮點，就是能在本地機器或云端實現(xiàn)跨團隊的管線內(nèi) build 緩存。

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

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

實用工具優(yōu)先的 CSS

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

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

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

配合 TypeScript 實現(xiàn)端到端類型安全

從 JavaScript 到 TypeScript 的演變已經(jīng)勢不可擋。在這場席卷整個 Web 開發(fā)世界的大遷移中，全棧應(yīng)用的端到端類型安全無疑是一大核心驅(qū)力。這個概念的實現(xiàn)與通信層（API）密切相關(guān)，因為通信層需要將類型化的實體（例如 type User、type BlogPost 等）從服務(wù)器橋接至客戶端應(yīng)用程序。

在涉及客戶端 -0 服務(wù)器通信的 Web 開發(fā)中，常見的選項是 REST 和 GraphQL。二者能與 OpenAPI for REST 和 GraphQL Code Generator for GraphQL 配合使用，為前端應(yīng)用程序生成類型化的 schema 文件。

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

構(gòu)建工具

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

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

Vite 的生態(tài)系統(tǒng)是伴隨著 Vitest（Jest 的測試替代方案）等新增功能而蓬勃發(fā)展，同時 Vercel 的 Turbopack 等同類競爭方案近期也開始涌現(xiàn)。Turbopack 被稱為 Webpack 的繼任者，因為它是由 Webpack 的締造者 Tobias Koppers 牽頭開發(fā)完成。由于 Next.js 既是 Webpack 的現(xiàn)用戶，一邊又是 Turbopack 的開發(fā)商，所以預(yù)計 Next.js 和 Turbopack 在后續(xù)將成為緊密關(guān)聯(lián)的一對 Web 組合。

AI 驅(qū)動開發(fā)

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

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

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

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

以上就是本次分享的全部內(nèi)容，想學習更多編程技巧，歡迎持續(xù)關(guān)注六星云課堂！