2023 年 WebAssembly 状态调查已经结束，结果已经出来，...，这些结果令人着迷！

要点如下：

• Rust 和 JavaScript 的使用率正在持续上升，但一些更值得注意的变化正在发生--Swift 和 Zig 的使用率都有显著上升。
• 说到开发人员 "渴望" 使用的语言，我们发现 Zig、Kotlin 和 C# 的渴望程度超过了当前的使用率。
• WebAssembly 仍然是网络应用程序开发中最常用的语言，但微服务器的使用率在持续上升，WebAssembly 作为插件环境的使用率也在上升。
• 线程、垃圾回收和相对较新的组件模型提案是人们最感兴趣的 WebAssembly 开发项目。
• 而在 WASI 中，最受关注的是 I/O 建议（如 HTTP、文件系统）。
• 我们有可能在社区中看到一些不耐烦的现象，人们对 WASI 发展的满意度明显低于对 WebAssembly 发展的满意度。
• 许多受访者表示，他们希望 WebAssembly 能够实现 Java 最初做出的 "一次编写，随处运行" 的承诺。

1.语言

第一个问题探讨了人们正在使用的语言，即 ”在开发使用 WebAssembly 的应用程序时，您使用或尝试过使用哪些语言？”

Rust 连续第三年成为 WebAssembly 使用最频繁的语言。Rust 一直以来都非常适合 WebAssembly，它是一种现代系统级语言，广受欢迎（根据Stack Overflow的调查，连续七年被评为最受欢迎的语言），同时也是编写 WebAssembly 运行时和平台的流行语言。

JavaScript 是第二种使用最广泛的语言，考虑到不能将 JavaScript 编译成 WebAssembly，这一点就非常值得注意。要运行 JavaScript 代码，需要将运行时编译成 WebAssembly，然后在 WebAssembly 托管的解释器中运行代码。这种方法听起来似乎效率不高，但却出人意料地实用，而且越来越受欢迎。你可能无法在速度上获得优势，但却能从 WebAssembly 的安全和隔离优势中获益。

下图显示了长期趋势，比较了最近三次调查的结果，以及使用每种语言（经常使用或偶尔使用）的人数比例，其中不包括使用率低于 10% 的人。

Rust 和 JavaScript 的使用率正在上升，但一些更值得注意的变化正在发生，Swift 和 Zig 的采用率都有显著增长。

Swift 是最近才加入 WebAssembly 生态系统的，几年前，苹果公司的 Swift 代码库中提出了一个拉取请求，要求添加一个 wasm 目标。然而，尽管多年以来有许多提交，但该拉取请求尚未合并。看起来社区并没有放弃，他们保持着自己的分支。

Swift 和 Rust 都是相当新的语言（分别是 2014 年和 2015 年），而 Zig 则更年轻，它出现于 2016 年，比 WebAssembly（其首个 MVP 版本发布于 2017 年）还要早一年。

今年，在调查中增加了一个新问题：你与 WebAssembly 的专业关系如何？ 目的是将积极开发 WebAssembly 工具或平台的人与单纯的最终用户区分开来。将这两类人区分开来，可以看到以下语言偏好：

不出所料，工具开发人员非常偏爱 Rust，也喜欢直接使用 WAT（WebAssembly 文本格式）对 WebAssembly 进行编程。此外，他们还非常喜欢 Go 和 Python，确实没有预料到。

调查的下一个问题是”你将来想用哪种语言来开发使用 WebAssembly 的应用程序？”，以此来探讨每种语言的可取性。

根据 Stack Overflow 的年度调查结果，Rust 再次名列榜首，JavasScript 位居第二。不过，使用频率较低的 Zig 语言在最受欢迎的语言中排名第三。

通过比较 “经常使用” 和 “非常想使用” 的回答之间的差异，我们可以看出在渴望程度方面哪些语言与使用率的差异最大：

在 Zig、Kotlin 和 C# 的一端，我们看到其受欢迎程度超过了当前的使用率，而在另一端，人们更希望减少使用 C++、JavaScript 和 WAT。

2.Runtime

考虑到 WebAssembly 在非浏览器的使用量在不断攀升，探索人们正在使用或只是知道哪些运行时是很有趣的，调查中只问了一个问题：您听说过或使用过哪些运行时？

Bytecode Alliance 的 wasmtime 是使用最广泛的运行时，排名第二的是由一家初创公司开发的 wasmer。Wazero 是该列表中的新成员，它是最近发布的一款 Go 语言运行时。

3.WebAssembly 的实际应用

调查询问了 你目前使用 WebAssembly 来做什么？，并允许人们选择多个选项并添加自己的建议。以下是所有的回答，其中“其他”包括只有一个回答的所有选项：

Web 应用程序开发仍居首位，但差距正在缩小。下图显示了逐年的发展趋势：

微服务器（Serverless）正在持续兴起，但最显著的转变可能是将 WebAssembly 用作插件环境。下面是一些现实世界中的例子：

• Zellij 是一个面向开发人员的终端工作空间，具有 WebAssembly 插件模型
• Microsoft Flight Simulator 允许您编写 wasm 模块作为插件
• Envoy 和 Istio 具有一个 Wasm 插件API
• 用 Rust 编写的新集成开发环境 Lapce 拥有基于 WASI 的插件系统

在每种情况下，平台（终端、编辑器、飞行模拟器、代理）都能受益于允许终端用户在安全隔离的环境中使用各种编程语言扩展功能。换句话说，如果有人编写的插件行为不端或性能不佳，对平台本身的影响将降到最低。

调查中还询问了受访者--贵公司采用 WebAssembly 的情况如何？

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

调查还探讨了 WebAssembly 需要哪些帮助来推动进一步的应用：

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

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

4.功能

WebAssembly（由万维网联盟（W3C）管理）和 WASI（由万维网联盟 WebAssembly 社区小组的一个子组织管理）都在不断发展，并按照标准的 5 阶段提案流程积压了大量新功能。

关于 WebAssembly 提案，以下内容显示了哪些建议是最受欢迎的：

线程、垃圾回收和异常处理在去年的评选结果中都名列前茅，这三者在提案生命周期中都处于实施（第 3 阶段）或标准化（第 4 阶段）阶段。这意味着它们已经可以使用，并接近最终确定。

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

关于 WASI 提案，以下是最受欢迎的提案：

最重要的四项提案都与 I/O 有关，简单地说，为 WebAssembly 模块创建一种与外界通信的标准方式是当务之急。

最后，询问了人们对 WebAssembly 和 WASI 发展的满意度：

有很多人对此并不满意！这一点也不奇怪，因为以公开透明的方式制定有众多利益相关者参与的规范并不容易，而且需要时间。更值得注意的是，人们普遍对 WASI 的发展不太满意。

Scott Logic 公司的首席技术官 Colin Eberhardt 提出一个重要的观点：这一结果不应该被用来直接批评 WASI 和 WebAssembly 小组所做出的巨大努力。对 WASI 的发展不满意可能只是反映了人们对这项技术的渴望，这并不是一件坏事。

今年早些时候，Wasmer 发布了 WASIX，试图加速 WASI（或其所代表的概念）的发展。

5.最后

WebAssembly 最让你兴奋的是什么？几乎有一半的受访者分享了他们的想法，远超过当前能真实概括的范围。因此，Colin 做了一件最明智的事，请 ChatGPT 总结了关键主题：

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