前沿開源技術(shù)領(lǐng)域解讀——開源大前端

近日，OSCHINA 和 Gitee 聯(lián)合發(fā)布了《2022 中國開源開發(fā)者報告》。

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

本篇為開源大前端領(lǐng)域的解讀。

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

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

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

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

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

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

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

工具鏈逐漸成熟，Wasm 云原生應(yīng)用逐漸走向主流

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

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

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

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

在操作系統(tǒng)層面，F(xiàn)edora Linux 37 與 Red Hat Enterprise Linux 的 EPEL 9 都正式集成了 WasmEdge 的安裝包。開發(fā)者可直接在 Linux 程序里集成 Wasm 應(yīng)用，或者用簡單命令行啟動 Wasm 的運行沙盒。

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

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

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

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

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

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

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

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

前后端開發(fā)的邊界越來越模糊

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

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

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

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

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

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

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

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

在線跑 JavaScript 越來越流行

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

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

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

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

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

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

2022 年前端趨勢總結(jié)

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

與多年前相比，微前端及類微前端模式已經(jīng)靈活多變：

微內(nèi)核模式，即胖 vendor + 插件式的瘦組件。

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

混合模式，即介于微內(nèi)核與微服務(wù)化模式，諸如半嵌入的微內(nèi)核模式。

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

現(xiàn)在，我們的挑戰(zhàn)變成：如何選擇合適的模式？

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

眾所周知，JavaScript 的工具鏈存在執(zhí)行速度的問題，主要體現(xiàn)在編譯方面，進而影響到開發(fā)和構(gòu)建速度。

Rust 作為 JavaScript 的基礎(chǔ)設(shè)施語言之一，在底層的 Node.js 生態(tài)方面，諸如 NAPI-RS 提供了使用 Rust 構(gòu)建預(yù)編譯 Node.js 原生擴展的能力。而圍繞編譯與構(gòu)建的 SWC、Parcel 等工具也提供了更快的開發(fā)體驗。

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

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

低代碼的另外一種聲音

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

值得一提的是，金融科技公司傾向于招聘會 Python 的業(yè)務(wù)人員?；蛟S，你需要真正懂數(shù)字化的業(yè)務(wù)？

瀏覽器智能

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

架構(gòu)模式：SDUI 與 Islands

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

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

Islands 架構(gòu)（孤島架構(gòu)）。孤島架構(gòu)鼓勵在服務(wù)器呈現(xiàn)的網(wǎng)頁中使用小的、集中的交互塊。Islands 的輸出是漸進式增強的 HTML，更具體地說明了增強是如何發(fā)生的。

這兩種模式依賴服務(wù)器來動態(tài)生成，還存在依賴 CDN 的動態(tài)生成模式。

邊緣 JavaScript

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

審核編輯 ：李倩