框架

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

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

盡管 Next.js 已經(jīng)是現(xiàn)代 SSR 領(lǐng)域的有力競爭，但其他框架也值得關(guān)注：

• SveltKit：基于 Svelte.js 構(gòu)建，其最新的 1.0 版本由 Vercel 支持；

• SolidStart：基于 Solid.js 構(gòu)建，其 DX 與 React 相比有所改進。

渲染模式

雖然過去 10 年（2010 年至 2020 年）一直由單頁應(yīng)用 (SPA) 和客戶端渲染 (CSR) 主導(dǎo)，從 Knockout.js 和 Ember.js 到 Angular.js、React.js 和 Vue.js，過去幾年，人們對使用元框架的服務(wù)端渲染 (SSR) 越來越感興趣。

從外部看來，這個周期似乎又要結(jié)束了，因為在多頁應(yīng)用 (MPA) 中使用 SSR 和 JavaScript（例如 jQuery、MooTools、Dojo.js）已經(jīng)很長時間了（2005 年至 2010 年）。雖然過去 Java（例如 JSP）或后來的 Ruby on Rails 已經(jīng)用于 SSR，但這次不同，因為我們依賴 JavaScript。近年來，Next.js 一直是這一趨勢背后的推動力，但其他元框架（如 SvelteKit）也正在迎頭趕上。

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

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

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

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

JavaScript運行時

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

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

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

Monorepos

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

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

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

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

實用優(yōu)先的 CSS

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

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

因此，我們可能會看到開發(fā)人員轉(zhuǎn)向?qū)?SSR 更友好的解決方案，例如將實用優(yōu)先的 CSS（例如 Tailwind CSS、UnoCSS）與預(yù)定義的 UI 組件（例如 DaisyUI）搭配使用?；蛘呤褂闷渌瑯恿餍械奶娲桨福?CSS Module，或稱為零運行時/編譯時的 CSS-in-JS（例如 vanilla-extract、linaria、astroturf）。

端到端類型安全

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

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

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

構(gòu)建工具

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

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

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

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

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

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

其他

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

• Tauri 成為 Electron 的替代方案用于由 JavaScript/CSS/HTML 實現(xiàn)的桌面應(yīng)用程序；

• Playwright 成為 Cypress 的 E2E （端到端測試）替代方案；

• Warp 和 Fig 成為下一代終端；

• CSS 容器查詢成為響應(yīng)式設(shè)計的 CSS 媒體查詢替代方案；

• htmx 作為一種豐富的 HTML，用于創(chuàng)建沒有 JavaScript 的交互式用戶界面。