近日，OSCHINA 和 Gitee 聯合發布了《2022 中國開源開發者報告》。

其中“前沿開源技術領域解讀” 部分，多位在其領域有所建樹的一線開發者和開源商業化公司創始人，對目前國內外流行的前沿開源技術領域過去的發展和未來的趨勢進行了深入的洞察，覆蓋開源云原生、開源 AI、開源大前端、開源大數據、開源 DevOps、RISC-V、開源操作系統、開源數據庫、編程語言九大領域。

本篇為開源大前端領域的解讀。

在大前端領域，我們看到了很多令人振奮的趨勢：Serverless/FaaS/邊緣計算等架構激發了對 Workload 被調度性能的追求，在線跑 JavaScript 越來越流行；JavaScript/TypeScript 在后端開發領域的應用越來越廣泛；一套代碼多平臺適配，跨平臺技術棧成為主流；WebGPU 在未來將取代 WebGL，會給 H5、小程序等的內容創作與性能表現帶來更多可能；工具鏈逐漸成熟，WebAssembly 云原生應用逐漸走向主流；低代碼/無代碼是大勢所趨·····

WebGPU 毫無疑問會在未來取代 WebGL

Web 一直是最開放和易于傳播的平臺，而今天游戲、元宇宙等數字內容非常依賴 Web 平臺的各種特性，但是 Web 環境中還沒有跟上 DirectX12、Vulkan、Metal 等現代圖形接口的變革。這一現狀隨著 WebGPU 標準的逐步完善，即將得到改變。這會給 Web 端帶來非常振奮人心的未來可能性。

WebGPU 是由 W3C GPU for the Web 社區組所發布的規范，目標是允許網頁代碼以高性能且安全可靠的方式訪問 GPU 功能。WebGPU 是一套為瀏覽器設計的次時代圖形 API 標準，為了彌合各個平臺圖形 API 的差異性，它對 DirectX12、Vulkan、Metal 進行了融合和封裝。借助 WebGPU，可以充分釋放現代 GPU 硬件的強大能力，讓開發者可以用 TS/JS 在 Web 端也開發媲美原生表現力的場景，實現更大型更復雜的 3D 場景表現，甚至使用現代 GPU 的通用計算能力完成之前無法想像的復雜計算任務。

自 2018 年起，Google Chrome 團隊就已經宣布著手 WebGPU 標準的實現工作。時至今日，WebGPU 的各類接口、生態、應用已日趨完善，WebGPU 1.0 或將于 2023 年初正式推出。而就在 2022 年 11 月，商用開源3D引擎 Cocos 發布了支持 WebGPU 的新版本 Cocos Creator 3.6.2，為國內首個支持該渲染后端的開源引擎。

作為 Google、Apple、Mozilla 等瀏覽器廠商共同推進的次時代圖形標準，WebGPU 毫無疑問會在未來取代 WebGL，這也是 Cocos 投資 WebGPU 技術的核心原因。目前 WebGPU 仍然在草案階段，不過已經鎖定了 v1.0 的目標，確保至少一家瀏覽器廠商完成全部 feature 的實現，正在全力推進中，預計很快就會完成 v1.0 里程碑。而且 Chromium、Safari、Firefox 等瀏覽器都已經開始推進實驗性實現，其中 Cocos 的 WebGPU 發布在 Chromium 中已經得到驗證。

從時間上來看，WebGPU 的出現時間稍晚，但也正因如此，讓 WebGPU 得以借助次時代圖形 API 的經驗，做出更好的設計。未來隨著 WebGPU 標準在主流瀏覽器的逐步落地，其能力將給 H5、小程序等的內容創作與性能表現帶來更多可能，也一定會在 Web 平臺出現不遜于原生 app 的圖形渲染效果，同時基于 Web 端的優勢給用戶帶來更輕量和便捷的體驗。

工具鏈逐漸成熟，Wasm 云原生應用逐漸走向主流

2022 年是云原生 WebAssembly （Wasm）工具鏈逐漸成熟的一年，也是 Wasm 的云原生應用逐漸走向主流的一年。相信在 2023 年，Wasm 的應用將會更廣泛。

2022 年，集成 WasmEdge 的 Docker Desktop 4.15 正式版發布。通過與 WasmEdge 合作， Docker 現在可以肩并肩運行 Wasm 容器 與 Linux 容器。Wasm 容器應用的啟動時間與空間占用也都比 Linux 容器改進了兩個數量級（100倍）。Docker 的支持是 Wasm 開發工具鏈步入主流的一個里程碑。

不僅如此，隨著 runwasi 成為 containerd 的正式項目，使得任何基于 containerd 的容器管理系統（包括 Docker 與 Azure）都能用 shim 的方式啟動 Wasm 容器。

兩個主流 OCI runtime——crun 與 youki 率先支持了 Wasm，Wasm 應用可以無縫接入現有 K8s 生態。CRI-O、Podman、OpenShift 與 K8s 及 K8s 的變種如 OpenYurt、SuperEdge、KubeEdge、kind 都可以啟動、編排 Wasm 容器。

在操作系統層面，Fedora Linux 37 與 Red Hat Enterprise Linux 的 EPEL 9 都正式集成了 WasmEdge 的安裝包。開發者可直接在 Linux 程序里集成 Wasm 應用，或者用簡單命令行啟動 Wasm 的運行沙盒。

Wasm 的語言支持也在逐漸增加。例如，通過 WasmEdge-quickjs 項目，JavaScript 程序（包括 Node.JS API 與 NPM 軟件包）可以運行在 Wasm 容器里。VMware 將 PHP 導入到 WebAssembly ，可以在 Wasm Runtime 運行 WordPress。微軟的 .Net 也增加了對 WASI 的支持。

在 Wasm 標準方面，Component model 提案將支持從一個 Wasm 模塊訪問其他模塊和系統（例如數據庫、消息隊列），提高 Wasm 模塊的可重用性和可組合性。spin、SpiderLightning 等項目已經在使用 component model 的一些接口與工具。wasmtime、WasmEdge 等主流 Wasm Runtimes 也都明確表示支持。

Wasm 在瀏覽器端也有了進展。W3C 發布了 WebAssembly 核心規范 2.0 的首個草案，討論了 Core Specification 、JavaScript Interface、Web API，為其在瀏覽器的應用指明了方向。

2022 年，Wasm 解鎖、豐富了幾個重要的云原生應用場景：

在微服務方面，Wasm 為其提供了輕量級、安全、高性能的運行環境。例如，wasmCloud 與 Adobe 合作部署了基于 Wasm 的安全微服務；基于 WasmEdge 的微服務也能夠直接使用 Dapr 集成的幾百種服務。

在數據流函數方面，作為一個輕量級、可嵌入的 runtime， Wasm 在數據庫 UDF 和數據流的 ETL 方面有落地應用場景。例如 SingleStore 與 Nebula Graph 使用 Wasm 在數據庫執行 UDF；InfinyOn 與 Redpanda 使用 Wasm 在實時數據流中處理數據。

在 PaaS serverless 函數方面，Wasm 非常適合執行輕量級，需要快速冷啟動擴容的 serverless 函數。Fermyon、Cosmonic 以及 Fastly 都基于 Wasm 推出了類似 AWS Lambda 的 Serverless 平臺。

在 SaaS serverless 函數方面， Wasm 可以賦能 SaaS 平臺支持用戶上傳的代碼。這些代碼是由 SaaS 事件觸發的，以取代復雜、慢且難用的 webhook APIs。Suborbital 推出了基于 Wasm 構建 SaaS 擴展的框架。而 Flows.network 是一個用 Wasm serverless 函數來連接 SaaS 的工具。

前后端開發的邊界越來越模糊

2022 年，這一年發生了很多大事，注定會被歷史銘記。寒冬已至， IT、互聯網行業裁員潮席卷全球，企業不得不去考慮如何降本提效。這一年，Flutter 發布 3.0 版本, 穩定支持 6 大平臺；Deno 完成 2100 萬美元 A 輪融資；國內低代碼/零代碼方向的開源項目不斷涌現，迭代翻新。

綜合各類新聞事件，可以看出幾大方向：

（1）JavaScript/TypeScript 在后端開發領域的應用越來越廣泛。2022 年，JavaScript 在 Github 語言使用榜單排名第一，繼續占據主導地位。在開源社區，你幾乎可以找到任何場景的 JavaScript 實現。NodeJS、Deno、Bun 等 runtime 賦予了 JavaScript 強大的后端能力，掌握 JavaScript，具備一定的數據庫、REST API 基本常識，即可獨立完成應用開發。

（2）跨平臺技術棧成為主流。一套代碼多平臺適配，為企業節省至少一半的研發成本。React Native、Flutter 等跨平臺方案更加成熟。使用 Flutter、React Native 等框架，開發效率更高，交互體驗與原生無異。

（3）低代碼/無代碼是大勢所趨。迫于成本壓力，企業更需要可以獨立完成應用開發的工程師。前后端技術也都朝著讓編程更簡單的方向發展。低代碼不僅不會替代工程師，反而對工程師的抽象設計能力有更高的要求，幫助工程師逃離無趣的業務邏輯，有更多時間學習思考創造。

在潮流涌動的當下，一種專門針對特定應用領域的計算機語言——DSL （domain specific language），被廣泛用于低代碼技術。使用 DSL，可以將常見功能抽象為 Table、Form 等部件之后，再組裝為應用，最后由 DSL 解釋器或編譯器將其翻譯為目標平臺代碼。事實上，從匯編到低代碼, 每一次編程語言的升級，都可以看成是在簡化程序的邏輯表述，把更多的工作交由編譯器(或解釋器)來完成，從而達到提高編碼效率的目的。

在人機交互細節方面，DSL 可以根據目標平臺特性分別實現。例如，同一段 Table DSL，在 WEB 端可以使用 React/VUE 實現，在移動端可以使用原生 SDK 實現，在游戲界面內可以使用游戲 UI 引擎實現，也可以使用 Flutter 等跨平臺 UI 框架統一實現。通過這種方式，可以更優雅地實現一套代碼多平臺適配，開發效率更高、無技術棧依賴，交互體驗等于各平臺原生。

前后端聯調、測試在應用開發過程中占用大量時間，而 DSL 組裝方案可以完美解決這個問題。將數據交互邏輯封裝到部件中，應用組裝時，為每個部件實例指定數據源，可節省大量前后端聯調測試時間。應用開發(組裝) 不再有前后端邊界，節省溝通成本，有效提升應用開發效率。

在線跑 JavaScript 越來越流行

過去一二十年，將 Javascript 跑在服務端的方式一直都存在，比如 Node.js、ASP 等。但近年來，這種將標準 Web API 規范跑在服務器上，進而實現 JavaScript Workload 的云邊端同構的技術方案，被提煉成了一個新概念——JavaScript Container 或者說 W3C Web-interoperable Runtime 的在線運行時。目前，很多廠商都參與在其中，比如國內的阿里、字節，海外的 Cloudflare、Shopify、Vercel。

究其原因，主要有兩個方面。一是 Serverless/FaaS/邊緣計算等架構激發了對 Workload 被調度性能的追求，JavaScript 是配合網頁出現的腳本語言，整個生態都是面向這一目標進行設計和優化的，包括啟動速度、部署密度、相對合理的執行效率等等。二是最近兩年 B/S 架構開始回歸。在移動化進程中，傳統 B/S 架構的 Web 逐步被冷落，甚至 B/S 中的 B（瀏覽器/WebView）也要先 HTML 白屏再加載一個 JS Bundle 再執行調用 API 展示頁面，導致用戶體驗劣化，工程效率也被分散。這對在線服務架構的易用度提出了新要求。

在被調度性能方面，JavaScript 也有較大優勢。在 Serverless 架構下，一門編程語言的被調度性能主要取決于三個因素：分發代碼包的大小、用代碼加載速度、內存占用。首先，在分發代碼包的大小方面，瀏覽器里面的 JavaScript 工具鏈很大一部分就是在解決這個問題，很容易移植到在線領域；其次，在代碼加載速度方面， JavaScript 引擎一般都在用戶代碼加載速度方面定向優化，比如各種熱啟動的機制；最后，在內存占用方面，JavaScript 雖然談不上很低，但與 JVM 一類相比，還是小很多。歸其原因，Serverless 動態實例擴容的技術挑戰，和 Chrome 里面新打開一個網頁 Tab 的技術挑戰，很多方面是重合的。

還有一個值得關注的方面是 JS 安全運行的問題。Node.js 是過去幾年最流行的 JavaScript 在線運行時。和 Python、Java 以及其他一切 Runtime 一樣，Node.js 提供了大部分的系統編程的能力，這正是不安全的來源。目前大部分編程語言 Runtime 本質上不僅僅是一個棧機，更多是在想辦法把系統調用、libc 等等能力封裝成一個又一個易用的編程語言 API，以解決在特定操作系統上單機編程的問題。我們是否可以通過只提供 Web 合規的 API，來盡可能將 JS 安全地運行在在線環境，從起點上屏蔽這些問題？

在標準與具體實現方面，JavaScript Container 已經取得了不小的進展。目前有 W3C WinterCG 來進行一些標準的協同，基本上還是以 Service Worker API 為基礎的一些擴展。而符合該標準的實現也比較多了，比如 Cloudflare Workers、EdgeRoutine、Deno、Noslate Workers 等等，Node.js 也對該標準在持續跟蹤。另一方面，Next.js 13、Midway 這些上層研發框架，也已經開始兼容這一標準的運行環境。

同時，這種模式在 WebAssembly 方向上也有這種發展路徑，比如最近新出來的 WasmEdge 項目，再比如前幾年的 Nanoprocess 概念。大家無非是想擁有一個具備真正 Serverless 體驗的編程環境和運維體系，靠技術的進步屏蔽運維成本。脫離系統 API 的安全性，高效的被調度性能，出了問題能被定位，這些做到后，我們將迎來真正的 Serverless。

2022 年前端趨勢總結

類微前端：豐富與靈活的各類模式

與多年前相比，微前端及類微前端模式已經靈活多變：

微內核模式，即胖 vendor + 插件式的瘦組件。

標準微前端模式，基于定制的底座，以使各個應用、組件完全獨立。

混合模式，即介于微內核與微服務化模式，諸如半嵌入的微內核模式。

無組件模式，諸如基于 Web Components、Islands 架構模式構建豐富的組件集。

現在，我們的挑戰變成：如何選擇合適的模式？

工具鏈：追求速度與非凡體驗

眾所周知，JavaScript 的工具鏈存在執行速度的問題，主要體現在編譯方面，進而影響到開發和構建速度。

Rust 作為 JavaScript 的基礎設施語言之一，在底層的 Node.js 生態方面，諸如 NAPI-RS 提供了使用 Rust 構建預編譯 Node.js 原生擴展的能力。而圍繞編譯與構建的 SWC、Parcel 等工具也提供了更快的開發體驗。

其它語言，諸如采用 Golang 語言的 ESBuild、采用 Zig 語言的 Bun 開發的 JS 運行時等。

接下來，我們要考慮的是兼容性。

低代碼的另外一種聲音

社區已經達成共識：針對不同的場景，構建不同的低代碼平臺。而對于中小型公司，還面臨著一個問題，開發人員響應“熱鬧驅動開發”開發了低代碼平臺，而這些低代碼平臺似乎并沒有真正體現價值？設計不出適合業務使用的體驗與流程？

值得一提的是，金融科技公司傾向于招聘會 Python 的業務人員。或許，你需要真正懂數字化的業務？

瀏覽器智能

在移動設備上運行 TensorFlow Lite，在邊緣型的嵌入式設備中能部署 AI 應用（tinyML），那么直接運行在瀏覽器上的 AI 也將變得流行（TensorFlow.js、ML5.js）。而我們還要面對模型體積帶來的網絡影響，如何平衡體積與質量成為了一種挑戰？

架構模式：SDUI 與 Islands

在 2022 年里，一些過去陌生的架構模式，也逐漸變得耳熟能詳。

Server Driven UI。在 SDUI 架構下，服務器返回的數據（JSON）會包含頁面的組件信息、布局以及數據類型等等，前端則根據這些信息來渲染 UI。從模式上來說，它與我們現今構建的低代碼模式極為類似，圍繞生成的 JSON 生成組件等的信息。相比之下，只是產出的結果和過程數據略有差異。

Islands 架構（孤島架構）。孤島架構鼓勵在服務器呈現的網頁中使用小的、集中的交互塊。Islands 的輸出是漸進式增強的 HTML，更具體地說明了增強是如何發生的。

這兩種模式依賴服務器來動態生成，還存在依賴 CDN 的動態生成模式。

邊緣 JavaScript

多年前，Cloudflare 公司提供了一個名為 Cloudflare Worker 的工具，可以在邊緣側執行應用程序。越來越多的主流框架支持這種方式，諸如 Next.js 的 Edge Runtime。簡單來說，CDN 廠商提供了一個動態的 JavaScript 服務器，讓代碼運行在邊緣側，以提高應用程序的訪問速度。其適合處理預處理場景，諸如授權等，也應用于 Islands 架構。

審核編輯 ：李倩