2023 年 WebAssembly 现状：第四种 Web 语言

2023 年度 WebAssembly 现状调查结果出炉，下面就来看看 2023 年的 WebAssembly 发展的怎么样了！

WebAssembly 是一种可移植、低级别的字节码语言，旨在提供一种通用的编译目标，以允许在 Web 上执行高性能计算密集型应用程序。它是一种新型的虚拟机技术，可以在所有主要的 Web 浏览器中运行，并且还可以在其他环境中使用。

 

WebAssembly 通过在 Web 浏览器中嵌入本地代码模块，能够直接访问底层系统硬件，实现了快速加载和执行的特性，因此被广泛认为是未来 Web 应用的基础技术之一。WebAssembly 可以与 JAVAScript 和其他 Web 技术协同工作，使开发人员能够使用多种编程语言来构建在线应用，并且具备高效、跨平台的特点。

 

WebAssembly 于 2019 年 12 月 5 日成为万维网联盟（W3C）的推荐标准，与 html，css 和 JavaScript 一起成为 Web 的第四种语言。

下面是本次调查结果概览：

• Rust 和 JavaScript 的使用量持续增加，但一些更显着的变化：Swift 和 Zig 的采用率都显着增加。
• 当谈到开发者所“渴望使用”的编程语言时，Zig、Kotlin和C#等语言的受欢迎程度超过了它们目前的实际使用率。
• WebAssembly 仍然最常用于 Web 应用开发，但 Serverless 正在持续兴起，使用 WebAssembly 作为插件环境的使用也在增加。
• 线程、垃圾回收和相对较新的组件模型提案是人们最感兴趣的 WebAssembly 发展方向。
• 对于 WASI（WebAssembly 系统接口），最受关注的是 I/O 提案（如 HTTP、文件系统）。
• 开发者对 WAI 发展的满意度明显低于对 WebAssembly 发展的满意度。
• 开发者希望 WebAssembly 能够兑现 Java 最初做出的“一次编写，到处运行”的承诺。

语言

在开发时利用 WebAssembly 的应用时使用或尝试过使用的语言统计如下：

Rust 连续第三年成为 WebAssembly 最常用的语言。Rust 一直非常适合 WebAssembly；它是一种广泛流行的现代系统级语言（Stack Overflow 连续七年显示它是最受欢迎的语言），它也恰好是一种用于编写 WebAssembly 运行时和平台的流行语言。

JavaScript 是第二广泛使用的编程语言。尽管无法直接将 JavaScript 编译为 WebAssembly，但可以通过将 JavaScript 代码运行时编译为 WebAssembly 来实现在 WebAssembly 中执行 JavaScript 代码的方式。在这种方法中，代码将在 WebAssembly 托管的解释器中运行。尽管可能会牺牲一些性能，但出人意料地实用，并且越来越受欢迎。虽然可能无法从速度上获得优势，但确实可以受益于 WebAssembly 的安全性和隔离性。

下图显示了长期趋势，将最近三次调查的结果进行比较，列出了每种语言的使用百分比（经常或偶尔使用），排除使用率低于10％的语言。

Rust 和 JavaScript 的使用率正在增加，但还有一些更显著的变化：Swift 和 Zig 的采用率均显着增加。

Swift 是 WebAssembly 生态系统中相对较新的成员，始于几年前对 Apple Swift 存储库的拉取请求以添加 wasm 目标。然而，尽管多年来进行了多次提交，但该 PR 尚未合并。

虽然Swift和Rust都是相对较新的语言（分别于2014年和2015年诞生），但Zig则更为年轻，于2016年出现，比WebAssembly（WebAssembly于2017年发布了第一个MVP版本）早一年。

今年，我们在调查中添加了一个新问题，旨在了解与 WebAssembly 相关的专业关系。我们的目标是将积极开发 WebAssembly 工具或平台的人员与最终用户的响应分开。通过将这两组分离，可以看到以下语言的偏好情况：

正如预期的那样，工具开发人员对 Rust 有着强烈的偏好，并且也喜欢直接使用 WAT（WebAssembly 文本格式）对 WebAssembly 进行编程。开发者对 Go 和 Python/ target=_blank class=infotextkey>Python 也有强烈的偏好。

对于问题“未来想使用哪些语言来开发利用WebAssembly的应用”，统计结果如下：

Rust 再次名列前茅，反映了年度 Stack Overflow 调查的结果，其次是JavaScript。然而，使用频率较低的 Zig 是第三个最受欢迎的语言。

通过绘制每种语言的差异，即“经常使用”的回答数量和“希望大量使用”的回答数量之间的差距，可以看出在受欢迎程度与使用率之间有着最大差异的语言：

可以看到，Zig、Kotlin 和 C# 的受欢迎程度超过了当前的使用率，C++、JavaScript 和 WAT 的当前的使用率超过了受欢迎程度。

运行时

考虑到WebAssembly在非浏览器环境下的使用正在增加，探索正在使用哪些运行时或者仅仅是听说过哪些运行时很有意思。这次调查只问了一个问题：“你听说过或使用过哪些运行时？结果如下：

wasmtime，来自于字节码联盟（Bytecode Alliance），是最广泛使用的运行时，而由一家初创公司开发的 wasmer 排名第二。Wazero 是一个新成员，它是一个基于 Go 语言构建的最近发布的运行时。

实际应用

使用 WebAssembly 的目的如下：

Web 应用开发仍然处于领先地位，但差距正在缩小。下图显示了同比趋势：

Serverless 正在持续增长，但可能最引人注目的转变是WebAssembly作为插件环境的使用。以下是一些实际应用的例子：

• Zellij是一个面向开发者的终端工作空间，它采用了WebAssembly插件模型。
• Microsoft Flight Simulator 允许将附加组件编写为 wasm 模块。
• Envoy 和 Istio 有一个 Wasm Plugin API。
• Lapce，一个用 Rust 编写的新 IDE，有一个基于 WASI 的插件系统。

在每种情况下，平台（终端、编辑器、代理）都从允许最终用户使用多种编程语言扩展功能的能力中受益，并且这些功能在一个安全而隔离的环境中运行。换句话说，如果有人编写了一个行为不端或性能较差的插件，对平台本身的影响将被最小化。

受访者所在组织采用 WebAssembly 的状况如下：

从上图中可以看到，41% 的受访者正在生产中使用 WebAssembly，还有 28% 的受访者正在试点或计划在明年使用它。

该调查还探讨了 WebAssembly 需要什么来帮助推动进一步采用：

被最频繁提及的需求是通过 WASI（WebAssembly系统接口）来改善非浏览器集成。WebAssembly 规范并未定义任何主机集成点，无论是如何访问 DOM 还是与主机运行时交换数据（例如在浏览器中将值传递给 JavaScript）。WASI正填补这一空白，但目前还没有完整的解决方案。

更好的调试支持紧随其后，随着人们使用 WebAssembly 开发越来越复杂的解决方案，这一点将变得更加重要。

特性

WebAssembly（由W3C管理）和WASI（由W3C WebAssembly社区组的子机构管理）都在不断发展，有一系列新功能遵循标准的5阶段提案过程。

关于 WebAssembly 提案，以下是最需要的：

线程、垃圾收集和异常处理在去年的结果中均名列前茅，并且这三者都处于提案生命周期的实施（第 3 阶段）或标准化（第 4 阶段）。这意味着它们已准备好使用，并且接近完成。

组件模型是一个处于早期阶段的提案（第 1 阶段），其目标是使在运行时以任何语言编写的 wasm 模块变得更加容易。

关于 WASI 提案，以下是最需要的：

四个最重要的提案都与 I/O 相关，可见，创建 WebAssembly 模块与外界通信的标准方式是当务之急。

受访者对 WebAssembly 和 WASI 的发展的满意度如下：

有很多人对这个情况表示不满意，这一点并不令人意外，以开放透明的方式演化的规范，涉及很多利益相关者，并不容易，并且需要时间。

不过，这个结果不应被用作直接批评 WASI 和 WebAssembly 团队所做出的出色努力。人们对 WASI 演进的不满可能只是对这项技术热情的反映，这并不是一件坏事。

小结

最后，来总结一下受访者对 WebAssembly 最兴奋的点：

• 可移植性和在不同平台上运行代码的能力。
• 不同语言和Web之间的互操作性。
• 本地性能和效率。
• 访问现有代码和库的能力。
• 新语言和工具的潜力。
• 安全性和沙箱功能。
• 替代容器并在浏览器中运行复杂堆栈的能力。
• 通用二进制格式的潜力。
• 编写一次，在任何地方运行的机会。
• 提高性能和速度。
• 组件模型和代码重用的能力。
• 减少或消除对JavaScript的依赖。
• 在语言选择上更灵活、多样化的选择。
• 插件系统的潜力。
• 在浏览器中运行复杂应用程序的潜力。