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

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

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

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

WebGPU 毫無(wú)疑問(wèn)會(huì)在未來(lái)取代 WebGL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在線跑 JavaScript 越來(lái)越流行

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

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

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

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

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

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

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

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

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

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

標(biāo)準(zhǔn)微前端模式，基于定制的底座，以使各個(gè)應(yīng)用、組件完全獨(dú)立。

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

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

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

工具鏈：追求速度與非凡體驗(yàn)

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

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

其它語(yǔ)言，諸如采用 Golang 語(yǔ)言的 ESBuild、采用 Zig 語(yǔ)言的 Bun 開(kāi)發(fā)的 JS 運(yùn)行時(shí)等。

接下來(lái)，我們要考慮的是兼容性。

低代碼的另外一種聲音

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

值得一提的是，金融科技公司傾向于招聘會(huì) Python 的業(yè)務(wù)人員。或許，你需要真正懂?dāng)?shù)字化的業(yè)務(wù)？

瀏覽器智能

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

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

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

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

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

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

邊緣 JavaScript

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

審核編輯 ：李倩