2023年WebAssembly调查结果显示

WebAssembly 2023 的调查已经结束，结果揭晓……真的很吸引人！

如果你想要简短的总结，这里有一些亮点：

• Rust 和 JavaScript 的使用仍在继续增加，但更值得注意的变化发生在下面—— Swift 和 Zig 的采纳率都有了显著的增长。
• 与此同时，当涉及开发者“渴望”使用哪种语言时，Zig、Kotlin 和C#的受欢迎程度超过了当前的使用情况。
• WebAssembly 仍然主要用于 web 应用程序开发，但无服务器技术的使用仍在增长，而作为插件环境的 WebAssembly 的使用也在增加。
• 线程、垃圾回收和相对新的组件模型提议是人们最感兴趣的 WebAssembly 发展方向。
• 至于 WASI，最受关注的是I/O提议（例如 HTTP、文件系统）。
• 我们可能看到社区中有些人变得不太耐烦，因为人们对WASI的发展满意度明显低于对 WebAssembly`的发展的满意度。
• 许多受访者表示，他们期望 WebAssembly 能够实现 Java 最初提出的“一次编写，到处运行”的承诺。

语言

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

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

JavaScript是使用最广泛的第二种语言，值得注意的是，因为不能将 JavaScript 编译为 WebAssembly。

要运行 JavaScript 代码，需要将运行时编译为 WebAssembly，并在 WebAssembly 托管的解释器中运行代码。这种方法听起来似乎效率不高，但却出人意料地实用，而且越来越受欢迎。

你可能不会获得速度优势，但确实可以从 WebAssembly 的安全性和隔离性中受益。想要进一步了解的话，作者推荐阅读 Shopify 团队的这篇深入文章，其中描述了他们如何支持用 JavaScript 编写的’Shopify 函数’，这些函数在 WebAssembly 平台上运行。

以下图表显示了长期趋势，比较了过去三次调查的结果，显示了每种语言的使用者比例（频繁或有时）——排除了<10%使用率的语言。

Rust 和 JavaScript 的使用正在增加，但其他更值得注意的变化正在下面发生。Swift 和 Zig 的采纳率都有了显著的增长。

Swift 是 WebAssembly 生态系统中一个相对较新的成员，它始于几年前苹果公司的 Swift repo 上的一个拉取请求，目的是添加一个 wasm 目标。然而，尽管多年来提交了无数次，该请求却一直未被合并。看起来社区并不气馁，他们正在维护自己的分支。

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

今年，作者在调查中添加了一个新问题，你与 WebAssembly 的专业关系如何？目的是将积极开发 WebAssembly 工具或平台的人员与单纯的最终用户区分开来。将这两类人分开后，我们发现他们对语言的偏好如下：

如预期，工具开发者对 Rust 有很强的偏好，还喜欢直接使用 WAT（WebAssembly 文本格式）编程 WebAssembly。还有对 Go和 Python 的强烈偏好——这是作者没想到的。

调查中的下一个问题探讨了每种语言有多么受欢迎，问了这样一个问题：在将来开发利用 WebAssembly 的应用程序时，你希望使用哪种语言？

Rust 再次名列榜首，反映了 Stack Overflow 的年度调查结果，JavasScript 位居第二。不过，使用频率较低的 Zig 语言则成为第三大最受欢迎的语言。

将每种语言 “经常使用 “的响应数与 “希望经常使用 “的响应数之间的Δ值绘制成理想度曲线，我们可以看到哪些语言的理想度与使用率之间的差异最大：

在 Zig、Kotlin 和 C# 的一端，我们可以看到可取性超过了当前的使用率，而在另一端，人们更希望少用 C++、JavaScript 和 WAT。

运行时

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

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

WebAssembly 的实际应用

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

Web 应用程序开发仍居首位，但差距有所缩小。下图显示了逐年变化趋势：

注意：在 2021 年/2022 年的调查中，Serverless 是wasm后端使用的唯一选项。到 2023 年，这被拆分成两个不同的类别，因此上述图表中 Serverless 的虚线。将 2023 年的两个选项组合在一起，后端使用会有轻微的增加。

最值得注意的转变是将 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 开发出更复杂的解决方案，这一点将变得更加重要。如需了解更多选项，请查看 Shopify 团队的这篇博文。

功能

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

关于 WebAssembly 建议，下面列出了最受欢迎的建议：

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

组件模型是一项更早期的提案（第 1 阶段），其广泛的目标是使在运行时以任何语言编写的 wasm 模块的组成更加容易。如果您对细节感兴趣，我推荐您观看由该提案的牵头人 Luke Wagner 播放的视频。

关于 WASI 提案，以下内容显示了哪些提案最受欢迎：

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

最后，执行询问人们对 WebAssembly 和 WASI 的发展有多满意：

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

作者想在这里提一个重要的观点；这个结果不应该直接作为对 WASI 和 WebAssembly 团队所做的出色努力的批评。对 WASI 发展的不满可能只是反映了人们对技术的渴望，这不是一件坏事。

今年早些时候，Wasmer 宣布了 WASIX，这是他们加速 WASI（或它代表的概念）的尝试，得到了混合的反应。