2023 年 8 大 Web 開發趨勢預測！

大家好，我是 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 領域的有力競爭，但其他框架也值得關注：

渲染模式

雖然過去 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 目前被視爲可行的替代方案。

其他

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

參考：https://www.robinwieruch.de/web-development-trends/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/awqA3nxa6uh1Xa0fq1eHcw

猜你喜歡