近日，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是由W3CGPUfortheWeb社区组所发布的规范，目标是允许网页代码以高性能且安全可靠的方式访问GPU功能。WebGPU是一套为浏览器设计的次时代图形API标准，为了弥合各个平台图形API的差异性，它对DirectX12、Vulkan、Metal进行了融合和封装。借助WebGPU，可以充分释放现代GPU硬件的强大能力，让开发者可以用TS/JS在Web端也开发媲美原生表现力的场景，实现更大型更复杂的3D场景表现，甚至使用现代GPU的通用计算能力完成之前无法想像的复杂计算任务。

自2018年起，GoogleChrome团队就已经宣布着手WebGPU标准的实现工作。时至今日，WebGPU的各类接口、生态、应用已日趋完善，或将于2023年初正式推出。而就在2022年11月，商用开源3D引擎Cocos发布了支持WebGPU的新版本，为国内首个支持该渲染后端的开源引擎。

作为Google、Apple、Mozilla等浏览器厂商共同推进的次时代图形标准，WebGPU毫无疑问会在未来取代WebGL，这也是Cocos投资WebGPU技术的核心原因。目前WebGPU仍然在草案阶段，不过已经锁定了的目标，确保至少一家浏览器厂商完成全部feature的实现，正在全力推进中，预计很快就会完成里程碑。而且Chromium、Safari、Firefox等浏览器都已经开始推进实验性实现，其中Cocos的WebGPU发布在Chromium中已经得到验证。

从时间上来看，WebGPU的出现时间稍晚，但也正因如此，让WebGPU得以借助次时代图形API的经验，做出更好的设计。未来随着WebGPU标准在主流浏览器的逐步落地，其能力将给H5、小程序等的内容创作与性能表现带来更多可能，也一定会在Web平台出现不逊于原生app的图形渲染效果，同时基于Web端的优势给用户带来更轻量和便捷的体验。

工具链逐渐成熟，Wasm云原生应用逐渐走向主流

2022年是云原生WebAssembly（Wasm）工具链逐渐成熟的一年，也是Wasm的云原生应用逐渐走向主流的一年。相信在2023年，Wasm的应用将会更广泛。

2022年，集成WasmEdge的正式版发布。通过与WasmEdge合作，Docker现在可以肩并肩运行Wasm容器与Linux容器。Wasm容器应用的启动时间与空间占用也都比Linux容器改进了两个数量级（100倍）。Docker的支持是Wasm开发工具链步入主流的一个里程碑。

不仅如此，随着runwasi成为containerd的正式项目，使得任何基于containerd的容器管理系统（包括Docker与Azure）都能用shim的方式启动Wasm容器。

两个主流OCIruntime——crun与youki率先支持了Wasm，Wasm应用可以无缝接入现有K8s生态。CRI-O、Podman、OpenShift与K8s及K8s的变种如OpenYurt、SuperEdge、KubeEdge、kind都可以启动、编排Wasm容器。

在操作系统层面，FedoraLinux37与RedHatEnterpriseLinux的EPEL9都正式集成了WasmEdge的安装包。开发者可直接在Linux程序里集成Wasm应用，或者用简单命令行启动Wasm的运行沙盒。

Wasm的语言支持也在逐渐增加。例如，通过WasmEdge-quickjs项目，JavaScript程序（包括与NPM软件包）可以运行在Wasm容器里。VMware将PHP导入到WebAssembly，可以在WasmRuntime运行WordPress。微软的.Net也增加了对WASI的支持。

在Wasm标准方面，Componentmodel提案将支持从一个Wasm模块访问其他模块和系统（例如数据库、消息队列），提高Wasm模块的可重用性和可组合性。spin、SpiderLightning等项目已经在使用componentmodel的一些接口与工具。wasmtime、WasmEdge等主流WasmRuntimes也都明确表示支持。

Wasm在浏览器端也有了进展。W3C发布了WebAssembly核心规范2.0的首个草案，讨论了CoreSpecification、JavaScriptInterface、WebAPI，为其在浏览器的应用指明了方向。

2022年，Wasm解锁、丰富了几个重要的云原生应用场景：

在微服务方面，Wasm为其提供了轻量级、安全、高性能的运行环境。例如，wasmCloud与Adobe合作部署了基于Wasm的安全微服务；基于WasmEdge的微服务也能够直接使用Dapr集成的几百种服务。

在数据流函数方面，作为一个轻量级、可嵌入的runtime，Wasm在数据库UDF和数据流的ETL方面有落地应用场景。例如SingleStore与NebulaGraph使用Wasm在数据库执行UDF；InfinyOn与Redpanda使用Wasm在实时数据流中处理数据。

在PaaSserverless函数方面，Wasm非常适合执行轻量级，需要快速冷启动扩容的serverless函数。Fermyon、Cosmonic以及Fastly都基于Wasm推出了类似AWSLambda的Serverless平台。

在SaaSserverless函数方面，Wasm可以赋能SaaS平台支持用户上传的代码。这些代码是由SaaS事件触发的，以取代复杂、慢且难用的webhookAPIs。Suborbital推出了基于Wasm构建SaaS扩展的框架。而是一个用Wasmserverless函数来连接SaaS的工具。

前后端开发的边界越来越模糊

2022年，这一年发生了很多大事，注定会被历史铭记。寒冬已至，IT、互联网行业裁员潮席卷全球，企业不得不去考虑如何降本提效。这一年，Flutter发布3.0版本,稳定支持6大平台；Deno完成2100万美元A轮融资；国内低代码/零代码方向的开源项目不断涌现，迭代翻新。

综合各类新闻事件，可以看出几大方向：

（1）JavaScript/TypeScript在后端开发领域的应用越来越广泛。2022年，JavaScript在Github语言使用榜单排名第一，继续占据主导地位。在开源社区，你几乎可以找到任何场景的JavaScript实现。NodeJS、Deno、Bun等runtime赋予了JavaScript强大的后端能力，掌握JavaScript，具备一定的数据库、RESTAPI基本常识，即可独立完成应用开发。

（2）跨平台技术栈成为主流。一套代码多平台适配，为企业节省至少一半的研发成本。ReactNative、Flutter等跨平台方案更加成熟。使用Flutter、ReactNative等框架，开发效率更高，交互体验与原生无异。

（3）低代码/无代码是大势所趋。迫于成本压力，企业更需要可以独立完成应用开发的工程师。前后端技术也都朝着让编程更简单的方向发展。低代码不仅不会替代工程师，反而对工程师的抽象设计能力有更高的要求，帮助工程师逃离无趣的业务逻辑，有更多时间学习思考创造。

在潮流涌动的当下，一种专门针对特定应用领域的计算机语言——DSL（domainspecificlanguage），被广泛用于低代码技术。使用DSL，可以将常见功能抽象为Table、Form等部件之后，再组装为应用，最后由DSL解释器或编译器将其翻译为目标平台代码。事实上，从汇编到低代码,每一次编程语言的升级，都可以看成是在简化程序的逻辑表述，把更多的工作交由编译器(或解释器)来完成，从而达到提高编码效率的目的。

在人机交互细节方面，DSL可以根据目标平台特性分别实现。例如，同一段TableDSL，在WEB端可以使用React/VUE实现，在移动端可以使用原生SDK实现，在游戏界面内可以使用游戏UI引擎实现，也可以使用Flutter等跨平台UI框架统一实现。通过这种方式，可以更优雅地实现一套代码多平台适配，开发效率更高、无技术栈依赖，交互体验等于各平台原生。

前后端联调、测试在应用开发过程中占用大量时间，而DSL组装方案可以完美解决这个问题。将数据交互逻辑封装到部件中，应用组装时，为每个部件实例指定数据源，可节省大量前后端联调测试时间。应用开发(组装)不再有前后端边界，节省沟通成本，有效提升应用开发效率。

在线跑JavaScript越来越流行

过去一二十年，将Javascript跑在服务端的方式一直都存在，比如、ASP等。但近年来，这种将标准WebAPI规范跑在服务器上，进而实现JavaScriptWorkload的云边端同构的技术方案，被提炼成了一个新概念——JavaScriptContainer或者说W3CWeb-interoperableRuntime的在线运行时。目前，很多厂商都参与在其中，比如国内的阿里、字节，海外的Cloudflare、Shopify、Vercel。

究其原因，主要有两个方面。一是Serverless/FaaS/边缘计算等架构激发了对Workload被调度性能的追求，JavaScript是配合网页出现的脚本语言，整个生态都是面向这一目标进行设计和优化的，包括启动速度、部署密度、相对合理的执行效率等等。二是最近两年B/S架构开始回归。在移动化进程中，传统B/S架构的Web逐步被冷落，甚至B/S中的B（浏览器/WebView）也要先HTML白屏再加载一个JSBundle再执行调用API展示页面，导致用户体验劣化，工程效率也被分散。这对在线服务架构的易用度提出了新要求。

在被调度性能方面，JavaScript也有较大优势。在Serverless架构下，一门编程语言的被调度性能主要取决于三个因素：分发代码包的大小、用代码加载速度、内存占用。首先，在分发代码包的大小方面，浏览器里面的JavaScript工具链很大一部分就是在解决这个问题，很容易移植到在线领域；其次，在代码加载速度方面，JavaScript引擎一般都在用户代码加载速度方面定向优化，比如各种热启动的机制；最后，在内存占用方面，JavaScript虽然谈不上很低，但与JVM一类相比，还是小很多。归其原因，Serverless动态实例扩容的技术挑战，和Chrome里面新打开一个网页Tab的技术挑战，很多方面是重合的。

在标准与具体实现方面，JavaScriptContainer已经取得了不小的进展。目前有W3CWinterCG来进行一些标准的协同，基本上还是以ServiceWorkerAPI为基础的一些扩展。而符合该标准的实现也比较多了，比如CloudflareWorkers、EdgeRoutine、Deno、NoslateWorkers等等，也对该标准在持续跟踪。另一方面，、Midway这些上层研发框架，也已经开始兼容这一标准的运行环境。

同时，这种模式在WebAssembly方向上也有这种发展路径，比如最近新出来的WasmEdge项目，再比如前几年的Nanoprocess概念。大家无非是想拥有一个具备真正Serverless体验的编程环境和运维体系，靠技术的进步屏蔽运维成本。脱离系统API的安全性，高效的被调度性能，出了问题能被定位，这些做到后，我们将迎来真正的Serverless。

2022年前端趋势总结

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

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

微内核模式，即胖vor+插件式的瘦组件。

标准微前端模式，基于定制的底座，以使各个应用、组件完全独立。

混合模式，即介于微内核与微服务化模式，诸如半嵌入的微内核模式。

无组件模式，诸如基于WebComponents、Islands架构模式构建丰富的组件集。

现在，我们的挑战变成：如何选择合适的模式？

工具链：追求速度与非凡体验

众所周知，JavaScript的工具链存在执行速度的问题，主要体现在编译方面，进而影响到开发和构建速度。

Rust作为JavaScript的基础设施语言之一，在底层的生态方面，诸如NAPI-RS提供了使用Rust构建预编译原生扩展的能力。而围绕编译与构建的SWC、Parcel等工具也提供了更快的开发体验。

其它语言，诸如采用Golang语言的ESBuild、采用Zig语言的Bun开发的JS运行时等。

接下来，我们要考虑的是兼容性。

低代码的另外一种声音

社区已经达成共识：针对不同的场景，构建不同的低代码平台。而对于中小型公司，还面临着一个问题，开发人员响应“热闹驱动开发”开发了低代码平台，而这些低代码平台似乎并没有真正体现价值？设计不出适合业务使用的体验与流程？

值得一提的是，金融科技公司倾向于招聘会Python的业务人员。或许，你需要真正懂数字化的业务？

浏览器智能

在移动设备上运行TensorFlowLite，在边缘型的嵌入式设备中能部署AI应用（tinyML），那么直接运行在浏览器上的AI也将变得流行（、）。而我们还要面对模型体积带来的网络影响，如何平衡体积与质量成为了一种挑战？

架构模式：SDUI与Islands

在2022年里，一些过去陌生的架构模式，也逐渐变得耳熟能详。

ServerDrivenUI。在SDUI架构下，服务器返回的数据（JSON）会包含页面的组件信息、布局以及数据类型等等，前端则根据这些信息来渲染UI。从模式上来说，它与我们现今构建的低代码模式极为类似，围绕生成的JSON生成组件等的信息。相比之下，只是产出的结果和过程数据略有差异。

Islands架构（孤岛架构）。孤岛架构鼓励在服务器呈现的网页中使用小的、集中的交互块。Islands的输出是渐进式增强的HTML，更具体地说明了增强是如何发生的。

这两种模式依赖服务器来动态生成，还存在依赖CDN的动态生成模式。

边缘JavaScript

多年前，Cloudflare公司提供了一个名为CloudflareWorker的工具，可以在边缘侧执行应用程序。越来越多的主流框架支持这种方式，诸如的EdgeRuntime。简单来说，CDN厂商提供了一个动态的JavaScript服务器，让代码运行在边缘侧，以提高应用程序的访问速度。其适合处理预处理场景，诸如授权等，也应用于Islands架构。

更多内容请查看《2022中国开源开发者报告》