前沿开源技术领域解读——开源大前端

近日，OSCHINA 和 Gitee 联合发布了《2022 中国开源开发者报告》。

其中 “前沿开源技术领域解读” 部分，多位在其领域有所建树的一线开发者和开源商业化公司创始人，对目前国内外流行的前沿开源技术领域过去的发展和未来的趋势进行了深入的洞察，覆盖开源云原生、开源 AI、开源大前端、开源大数据、开源 DevOps、RISC-V、开源操作系统、开源数据库、编程语言九大领域。

本篇为开源大前端领域的解读。

在大前端领域，我们看到了很多令人振奋的趋势：Serverless/FaaS/边缘计算等架构激发了对 Workload 被调度性能的追求，在线跑 JavaScript 越来越流行；JavaScript/TypeScript 在后端开发领域的应用越来越广泛；一套代码多平台适配，跨平台技术栈成为主流；WebGPU 在未来将取代 WebGL，会给 H5、小程序等的内容创作与性能表现带来更多可能；工具链逐渐成熟，WebAssembly 云原生应用逐渐走向主流；低代码/无代码是大势所趋·····

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 端的优势给用户带来更轻量和便捷的体验。

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 跑在服务端的方式一直都存在，比如 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。

类微前端：丰富与灵活的各类模式

与多年前相比，微前端及类微前端模式已经灵活多变：

• 微内核模式，即胖 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 架构。