2023 年 8 大 Web 開發趨勢預測

語言: CN / TW / HK

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

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

(元)框架

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

image.png

流行的 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(在客戶端上按需獲取個人資料)之間做出選擇。

image.png

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)。

image.png

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 Usertype 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 很快就過時了。

image.png

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 媒體查詢替代方案;
  • htmx 作為一種豐富的 HTML,用於建立沒有 JavaScript 的互動式使用者介面。

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