大家好，我是 CUGGZ。開工第一天，祝大家開工大吉，事業新啟，前兔無量！

本文將分享通過 State of JS 2022 調查結果 總結的 2023 年 8 大 Web 發展趨勢！

（元）框架

單頁應用 (SPA) 及相關框架（例如 React.js、Vue.js、Svelte.js）都已經存在了很多年。然而，隨著這些解決方案之上的元框架的興起，可以看到應用從客戶端渲染（CSR）轉向服務端渲染（SSR）的明顯趨勢。如今，在使用 JavaScript 框架時，SSR 無處不在。

流行的 Next.js 的元框架建立在 React 之上。React 核心開發人員 Andrew Clark 將其稱為 2022 年的“真正的 React 18 版本”，因為它附帶了 React 團隊作為較低級別的基本構建塊提供的所有功能（例如 Suspense、流式 SSR）。Vercel（Next.js 背后的公司）和 React 核心團隊正在密切合作，提供出色的開發者體驗。Remix（最近被 Shopify 收購）是 Next.js 替代品，它采用不同的方法將 React 轉變為元框架（例如，使用 Web 標準作為一等公民）。

盡管 Next.js 已經是現代 SSR 領域的有力競爭，但其他框架也值得關注：

• SveltKit：基于 Svelte.js 構建，其最新的 1.0 版本由 Vercel 支持；
• SolidStart：基于 Solid.js 構建，其 DX 與 React 相比有所改進。

渲染模式

雖然過去 10 年（2010 年至 2020 年）一直由單頁應用 (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）也正在迎頭趕上。

SSR 已經與靜態站點生成 (SSG) 競爭了很長一段時間，以獲得完美的性能（參見 Next.js 與 Gatsby.js），盡管這兩種模式的用途完全不同。后一種模式用于靜態內容（例如博客等網站），而前者用于動態內容（例如 Web 應用）。由于需要高度動態的內容或以用戶為中心的內容并進行身份驗證，開發人員不能選擇 SSG（在部署前構建一次，因此是靜態的），而必須在 SSR（根據服務器上的單個數據請求按需構建）或 CSR（在客戶端上按需獲取個人數據）之間做出選擇。

CSR、SSR、SSG 并不是渲染技術的最新趨勢。雖然 SSR 和 SSG 在幾年前開啟了性能優化趨勢，但增量靜態再生 (ISR) 和流式 SSR 等更細分的渲染技術開始活躍起來。前者推進了 SSG，因為它允許在每個頁面的基礎上靜態重新構建網站（例如，每 60 秒重新構建頁面 X）而不是重新構建整個網站。按需 ISR，也稱為按需重新驗證，可用于通過應用公開的 API 觸發重新構建（例如，當 CMS 數據更新時）。

另一方面，Streaming SSR 優化了服務端渲染的單線程瓶頸。普通 SSR 必須在服務器上等待數據將渲染的內容立即發送到客戶端，而流式 SSR 允許開發人員將應用分成塊，這些塊可以逐步從服務器并行發送到客戶端。

在過去幾年中，SPA/MPA 中的 SSG 和 SSR 渲染模式非常簡單。然而，如今更細分的版本正在流行，除了 ISR 和流式 SSR，部分水合（例如 React 服務端組件）允許僅在客戶端上水合某些組件，漸進式水合可以對水合順序進行更細粒度的控制，Island 用于 MPA 中的隔離應用或組件的架構（例如 Astro ）以及使用可恢復性而不是水合作用（例如 Qwik）。

JavaScript運行時

2009 年，Ryan Dahl 在一次會議上宣布了 Node.js。最初 Node.js 只是一項將 JavaScript 與瀏覽器分離并使其在服務器上可用的實驗，后來成為 JavaScript 在過去十年中取得成功的最大推動力之一。Ryan Dahl 在沒有瀏覽器的情況下為 Node.js 使用了稱為 V8 的 JavaScript 引擎（由 Chrome 實現）。因此，Chrome 瀏覽器和 Node.js 使用相同的 JavaScript 引擎，但有自己的 JavaScript 運行時（例如瀏覽器 API 與 Node.js API）來與之交互。

十年后，Ryan Dahl 宣布 Deno 成為 Node 的繼任者，并承諾為開發人員提供一個更安全、更快速的環境，其中包括類似瀏覽器 API、TypeScript 和開箱即用的標準庫。Deno 也運行在 V8 上，不過如今它只是眾多 JavaScript 運行時中的一種。

在邊緣計算的競爭領域，許多云提供商實現了自己的 JavaScript 運行時（例如 Cloudflare Workers），它針對自己的基礎設施（例如 Cloudflare）進行了優化。因此，Deno 的業務模型也正在成為一個云提供商，擁有 Deno Deploy 和它們的即時邊緣渲染 SSR 框架（最初作為概念驗證），稱為 Deno Fresh。像 Bun 這樣的獨立于云提供商的解決方案最近成為最快 JavaScript 運行時競爭中的另一個熱門話題。

Monorepos

在過去，monorepos 主要用于大型應用，一個項目在一個版本控制的存儲庫中包含較小的項目。這些較小的項目中的每一個都可以是從單個應用程序（例如 SPA、MPA）到可重用包（例如函數、組件、服務）的任何東西。合并項目的做法可以追溯到 2000 年初，當時它被稱為共享代碼庫。

如今，monorepos 不再是大型應用的專屬，很多小型公司和開源項目也可以從中受益。例如，一家公司可以在 monorepos 中擁有各種包，包括共享 UI 組件、共享設計系統（例如可重用協作設計）以及各自領域的常用實用函數。

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

Turborepo（被 Vercel 收購）再次在 JavaScript/TypeScript 中宣傳 monorepo。Turborepo 允許團隊在 monorepo 中為他們所有的應用和包創建構建管道。引人注目的是：在本地機器或跨團隊的云中的管道內緩存構建。Turborepo 與 npm/yarn/pnpm 工作區（依賴管理）和變更集（版本控制）等其他重要的 monorepo 工具相結合，使該工具鏈成為今年值得關注的領域。

實用優先的 CSS

Tailwind CSS 是實用優先 CSS 的典型代表。一方面開發人員討厭它在 UI 代碼中顯得冗長，另一方面又喜歡它出色的 DX。作為開發人員，只需在項目中對其進行一次配置，即可立即在 HTML 中使用其預定義的 CSS。

不過，隨著最近服務端渲染 (SSR) 的興起，這種關于實用優先 CSS 的愛與恨的分歧可能會結束。近年來，像 Styled Components (SC) 和 Emotion 這樣的 CSS-in-JS 解決方案一直是現代基于組件的 Web 應用樣式的主導力量。然而，如果使用 SSR 的主要目標是高性能，那么 CSS-in-JS 就會帶來負面影響：增加包大小（SC 為 12.7kB，Emotion 為 7.9kB），更重要的是，在將其插入 DOM 之前，由于 CSS 序列化，運行時開銷增加。

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

端到端類型安全

從 JavaScript 到 TypeScript 的演變是不可阻擋的。在這場 Web 開發的大遷移中，全棧應用的端到端類型安全無疑是一個重要的趨勢。這個概念的實現與通信層 (API) 相輔相成，通信層是將類型化實體（例如：??type User??、??type BlogPost??）從服務端橋接到客戶端應用所需的。

在用于客戶端-服務端通信的 Web 開發中，通常會使用 REST 和 GraphQL。兩者都可以與 OpenAPI for REST 和 GraphQL Code Generator for GraphQL 一起使用，為前端應用生成類型化的模式文件。

有一個名為 tRPC 的類型安全 API 成為后起之秀，它可以作為 REST/GraphQL 的替代品。如果使用在前端和后端共享代碼的 TypeScript monorepo，tRPC 可以將所有類型從后端導出到前端應用，而無需任何類型化模式的中間生成。之后，前端只需使用在后臺通過 HTTP 連接的類型化函數即可調用后端的 API，以實現客戶端-服務端通信。總體趨勢肯定會朝著使用更多此類類型安全解決方案的方向發展，用于全棧應用，例如 tRPC、Zod、Prisma 和 TanStack Router，它們都在應用中提供類型安全。

構建工具

在 React 中，create-react-app (CRA) 主導了幾年。這在當時是一場革命，因為初學者獲得了一個隨時可用的 React 入門項目，而無需再使用 React 設置配置自定義 Webpack。然而，在過去的一年里，Webpack 很快就過時了。

Vite 是構建單頁應用 (SPA) 的新秀，它適用于所有流行的框架（例如 React、Vue）來創建入門項目。由 Vue.js 的創建者尤雨溪實現，將 Vite 定位為下一代前端工具。在 Vite 內部，它從 esbuild 獲得了強大的功能，與其他 JavaScript 構建工具相比，它是用 Go 編寫的，因此打包依賴項的速度比其競爭對手（例如 Webpack）快 10-100 倍。

Vite 的生態系統隨著 Vitest（Jest 的替代品）等新增功能而蓬勃發展。但最近出現了新的競爭對手，如 Vercel 推出的 Turbopack。Turbopack 被稱為 Webpack的繼任者，因為它是由 Webpack 的創始人 Tobias Koppers 主導推出的。Next.js 目前仍然在使用 Webpack，它和 Turbopack 是由同一家公司開發的，所以預計 Next.js 和 Turbopack 可能會在未來成為完美搭配。

AI 驅動的開發

AI 最終會接管開發者的工作嗎？這個問題目前還沒有答案，但是，AI 驅動的開發在 2022 年成為了現實。隨著 GitHub Copilot 的發布，開發人員能夠在喜歡的 IDE 中使用 AI 程序。只需編寫代碼（或寫一條注釋說明想編寫什么代碼），GitHub Copilot 就會自動完成實現細節。

但 AI 驅動開發并不止于此：OpenAI 的 ChatGPT 是一種更通用的語言模型，它也可以完成編程任務。許多開發人員已經使用 ChatGPT 作為了 StackOverflow 的替代品。在許多情況下，當用作搜索引擎替代品時，ChatGPT 會提供有用的答案（盡管并不總是完美的）。因為搜索引擎必須處理大量的 SEO SPAM（不僅與開發相關的內容），ChatGPT 目前被視為可行的替代方案。

其他

除了上面提到的趨勢，還有很多值得一提的地方：

• Tauri 成為 Electron 的替代方案用于由 JavaScript/CSS/HTML 實現的桌面應用程序；
• Playwright 成為 Cypress 的 E2E （端到端測試）替代方案；
• Warp 和 Fig 成為下一代終端；
• CSS 容器查詢成為響應式設計的 CSS 媒體查詢替代方案。