本文作者：Colin Eberhardt
原文链接：https://blog.scottlogic.com/2022/06/20/state-of-wasm-2022.html
本文的翻译与传播已获得原作者 Colin 的授权。
2022年 WebAssembly 状态调查已经结束，结果新鲜出炉——有些很有趣的发现！
去年 WebAssembly 经历了相当大的转变，虽然 Wasm 语言格局变化缓慢，但是人们使用 WebAssembly 的目的发生了显著变化。Wasm 在 Serverless、容器化和作为插件技术等方面的应用有了很大的飞跃，WebAssembly 系统接口 （WASI）变得越来越重要。
想知道更多？让我们来看看细节。
我去年也做了同样的问卷调查，我们了解到：
Rust 是人们最常用和最需要的 WebAssembly 语言。
AssemblyScript 是第二受欢迎的 WebAssembly 语言。
WebAssembly 预计将对 Web、Serverless、游戏和容器化应用程序产生重大影响。
更好的 debug 支持是人们认为最需要关注的领域。
那么，今年有哪些新的结论呢？在讨论细节之前，我们先看看关键点：
JavaScript 已经成为一种可行的 WebAssembly 语言。
对于 Blazor 而言，其过去一年有长足发展，使用率和受欢迎度都高度提升。
Wasmtime 是使用最广泛的 runtime。
WebAssembly 在 Serverless、容器化和作为插件主机方面的使用量显著增加。
非浏览器 API 是 WebAssembly 最需要的。
对于 WebAssembly 来说，这是相当不错的一年！接下来，我们将更详细地研究调查结果，并探讨其中的一些变化。该问卷直接沿用了去年的许多问题，方便直接与去年做对比。去年共有250名受访者，今年增加到了299名。
第一个问题为了探索人们正在使用哪些开发语言，询问了受访者您正使用哪些语言，或者是否尝试过使用 WebAssembly 开发?
Rust 再次名列第一，45%的人表示他们经常或有时使用它。WebAssembly 和 Rust 确实有相当密切的关系，大多数 WebAssembly runtime 都是用 Rust 编写的，基于 wasm 的各种平台也是如此。它还拥有一些最好的工具，所以排第一并不令人意外。
今年，JavaScript 排在第二位。去年我没有添加 JavaScript 选项（也没有人通过“其他”选项表示他们使用它），这是和去年相比的一个重大变化！
JavaScript 无法编译为 WebAssembly，那么它是如何工作的呢？对于这一挑战，有一个巧妙的解决方法：可以将 JavaScript 引擎编译为 WebAssembly ，然后用它来执行代码，而不是将 JS 编译为 Wasm。这实际上比想象的要实用得多。
今年，67%的受访者表示经常使用 WebAssembly，这比去年的47%有很大的提升。
下图显示了与去年相比，使用给定语言“经常”或“有时”的受访者百分比：
该图表明 Rust 的使用量稳步攀升，但上升最多的是 Blazor 和 Python。Pyscript ，一个交互式在线游乐场的推出，无疑对 Python 意义重大。AssemblyScript 的使用量下降幅度最大，这让我有点吃惊。我想知道是否有些受访者错误地将 AssemblyScript 认定为 JavaScript？
下一个问题询问的是人们最想使用哪种语言进行 WebAssembly 开发：
毫无意外，Rust 名列前茅。在过去的六年里，它在 StackOverflow 调查中一直稳居“最受欢迎”语言的榜首。
让我们看看它与去年相比如何：
Rust 的受欢迎程度略有上升，但上升最快的是 Blazor，Go 紧随其后。
对于 Blazor 来说，这是非常不错的一年！
接下来，我们来看看大家使用 WebAssembly 的目的，以及他们未来的期望。
调查询问您目前使用 WebAssembly 的目的是什么？可多选，或者输入自己建议的其它答案 。以下是所有回复，其中“其他”包括只有一个回复的所有内容：
大多数人都在使用 WebAssembly 进行 Web 开发。但是，如果我们将今年的结果与去年的结果进行比较，就会发现一些很大的变化：
WebAssembly 在 Serverless 和容器化方面的使用有所提升。如果你想知道为什么 WebAssembly 对这些应用程序来说是一项如此重要的技术，我推荐这篇文章《请关注 WebAssembly》 ，或这篇《当 WebAssembly 取代 Docker 之时》，它们涵盖了今年在 Kubecon 上的各种讨论。
最大的增长是 WebAssembly 作为插件环境的应用。它是在安全环境中托管不受信任代码的绝佳 runtime。Lapce 代码编辑器就是一个很好的例子。
WebAssembly 在游戏中的使用下降了，但我不清楚其原因是什么🤷
考虑到基于非浏览器的 WebAssembly 使用情况如何发展的问题，今年我提出了一个关于 runtime 的新问题——你听说过或使用过哪些 runtimes？
来自字节码联盟的 wasmtime，得到了最广泛的使用；其次为 wasmer，它由一个初创公司所开发。
WebAssembly 遵循由 W3C 管理的公共提案流程。该调查囊括了在第 2 阶段（可用规范）和第 3 阶段（实现）的更成熟的特性提案，并询问了大家对哪几项最感兴趣。
添加了 shared linear memory 和 atomics 的线程提案名列前茅，其次是对 exception 和垃圾收集的支持。
WebAssembly 系统接口（WASI），为 WebAssembly 添加了进一步的系统级集成 API，正变得越来越重要，所以问卷还询问了人们对哪些 WASI 提案感兴趣：
I/O 类型排在首位，其次是 socket、文件系统和本机线程。值得注意的是，如果您将此图表与前面 WebAssembly 提案的图表相比较，那么可以发现整体而言人们对 WASI 的兴趣要大得多。
最后，问到受访者你认为 WebAssembly 在未来取得成功最需要的是什么？
non-brower API 名列前茅，这进一步凸显了人们对 WASI 的兴趣以及 WASI 的重要性。
最后，该调查包括了一些人口分布的问题。这里简要分享下数据。
受访者需勾选他们的 JavaScript、后端和 WebAssembly 开发技术水平：
有趣的是，去年的调查受访者显示最精通 JavaScript 和前端开发，今年的调查则吸引了具有更高后端能力的开发者，这很可能反映了 WebAssembly 焦点的不断变化。
他们还被问及使用 WebAssembly 或了解 WebAssembly 的时间。
今年的受访者显然更有经验，与上一次的“＜1 年”相比，大部分人回答是有 2 年左右的经验。
感谢所有参与本次调查的人。如果您想进行自己的分析，可以下载本 CSV 文件（https://wasmweekly.news/assets/state-of-webassembly-2022.csv）。如果另有发现任何有趣的结果，请务必和大家分享。
正如我在引言中所提及，对于 WebAssembly 来说，今年是相当重要的一年。虽然之前就确定 WebAssembly 正在向通用 runtime 转变，但未预料到变化如此显著。
