社区分裂、应用争议，5年都没火起来的WebAssembly “炒错”方向了？

WebAssembly（Wasm）已经诞生了五年。在云原生领域，这段时间并不算短，毕竟堪称业界标准的 Kubernetes 也才出现八年。作为一种供基于堆栈的虚拟机使用的二进制指令格式，Wasm 想让开发者实现“一次构建、随处运行”，因此被广泛认为具有改变游戏规则的潜力。

但 HTTP Archive 发布的 2022 年 Web 技术报告显示：“WebAssembly 的应用还不够广泛，我们并没有发现使用量的增加，反而看到了小幅收缩。”

WebAssembly 语言使用情况，图源：https://almanac.httparchive.org/en/2022/webassembly#fig-5

这份报告基于对 800 多万个网站的调查，这些网站是谷歌 Chrome Chrome UX Report（用户体验报告）所分析的网站。据 Netcraft 的月度调查显示，有超过 11 亿个网站，但其中许多网站并不活跃，因此这份报告仅针对那些最活跃的网站。

需要注意的是，通常情况下，网络爬虫并不会登录 Web 应用，它们只能浏览网站上的公开内容，因此这项调查并不包括那些使用中的 Web 技术应用。当涉及更加以应用为核心的技术时，则可能会导致结果失真，包括 WebAssembly。

尽管如此，在报告中撰写 WebAssembly 分析的技术博主 Colin Eberhardt 并没有放弃，他指出，网页中的 Wasm（编译的 WebAssembly 代码）数量很少：

“我们发现，在桌面上有 3204 个确认的 WebAssembly 请求，移动端有 2777 个。这些模块被用于桌面上的 2524 个域名和移动上的 2216 个域名，分别占桌面和移动上所有域名的 0.06%和 0.04%。”

对该 Wasm 的分析表明，到目前为止，最大的份额是亚马逊 IVS（互动视频服务），这是 AWS Chime 服务用于优化视频通信的库模块。这并不代表开发者有意为之，仅仅是使用这种特定的 AWS 服务的结果。也许更重要的是，微软的 Blazor 框架出现在最普遍 Wasm 使用的第三位，因为这将是开发者为特定网站而编写的代码。

流行的 WebAssembly 库，图源：https://almanac.httparchive.org/en/2022/webassembly#fig-4

Eberhardt 认为，目现在还没有充分的理由去使用 WebAssembly，原因是 Wasm 代码不能替代 JavaScript，它只能作为 JavaScript 的补充。他认为，WebAssembly 的未来可能不是“作为一个小众的 Web 技术，而是作为一种在其他平台上完全主流的运行时”。

为什么 Wasm 就一直火不起来？虽然有各种各样的原因，但 Wasm 自身生态系统的震荡不定却是难辞其咎。

AssemblyScript 的分裂

最近几周，Wasm 生态的问题再度暴露无遗。

AssemblyScript 是一种专为 Wasm 在浏览器中使用所设计的语言。最近，其宣布不再支持 WASI——一种易于在浏览器之外使用的 Wasm 系统接口。目前还不清楚 AssemblyScript 到底为什么要放弃 WASI，但理由大概率还是在技术和观点层面有分歧。

WASI 项目提案侧重于 Wasm 与 Rust、C++等语言的互操作性，相对牺牲了 JavaScript，而这最终会损害 AssemblyScript（具有 TypeScript 特性）的利益，并迫使其在项目层面做出重大更改。

AssemblyScript 的作者们通过线上文档《对标准的反对意见》提出，W3C 的 WASI 子团队“扩大了职能范围”，其“设计的自有提案……会与既定或当前设计的 Web 标准相竞争。”

除此之外，作者们还表示，“我们的代表受到了系统性歧视，没人在乎他们表达的担忧和反对。”

再者，AssemblyScript 还将矛头指向 Bytecode 联盟。该联盟拥有多家重量级技术成员，包括亚马逊、谷歌和微软三大云服务巨头，专司为 Wasm 和 WASI 提供支持。

AssemblyScript 的作者们警告称，“我们想提醒公众，应密切关注潜在的反竞争行为。有必要的时候，甚至应该要求反垄断立法的介入。”

这里再介绍一点相关背景：有数据表明，人们对于 AssemblyScript 的关注正在下降。在 Scott Logic 今年 6 月发布的《2022 年 WebAssembly 现状调查》中，只有 17%的受访者表示有意在未来大量使用 AssemblyScript，比例远低于 2021 年调查时的 26%。

虽然这一结果可能跟 Wasm 项目范围扩大而导致 AssemblyScript 用量稀释有关，但必须承认，当前对开发者吸引力最大的仍然是 Go 和 JavaScript 那几种热门语言。AssemblyScript 在其中的确缺乏竞争力。

至于反竞争指控，虽然 Bytecode 联盟的成员名单确实有利益集团绑定的嫌疑，但这更多是种对强势技术趋势的主动参与，未必代表各方打算强行通过有利于自己的议程。

Bytecode 联盟成员、边缘云平台厂商 Fastly 公司首席技术官 Tyler McMullen 表达了他对这波冲突的失望之情。

McMullen 强调，症结其实就是“一个非常细微的技术细节——是否允许在客串中包含某些无效代码点。” 他指出，这个“技术细节”的决定并不是某个人或一家公司说了算，“提案经过了整个行业中很多专家的审查和投票，包括各家主要浏览器开发商。”

开源平台工具厂商 Suborbital 工程总监、Grain 编程语言联合缔造者 Oscar Spencer 也有类似判断：

“这可能引发碎片化趋势，阻碍标准的发展和进步，肯定不利于建立起有凝聚力的生态系统。”

推广 Wasm 的力量来源并非用户

鉴于这样的冲突和分歧，整体软件社区找不到使用 Wasm 的理由和必要性。

尽管 Wasm 最初专门为浏览器所设计，但现在这类用例似乎不是特别重要。大家更多的关注和兴趣主要集中到 Wasm 在浏览器之外的潜力，例如在服务器上使用（有望与 Docker 结合使用，甚至直接替代 Docker），或者通过代码捆绑实现跨多应用程序运行。

Spencer 对于 Wasm 的发展历程也有自己的看法：

“我们最终看到……JavaScript 引擎其实已经很快了。单纯用 Wasm 重写现有应用程序，其实并不一定能让它变得更快，毕竟 JavaScript 引擎已经有了几十年的积累，目前非常成熟且完善。” “正因为如此，在浏览器上用 Wasm 编写完整应用程序的需求越来越少。现在的开发者更多在用 Wasm 编写那些对速度比较敏感的后台任务。”

但这并不是说 Wasm 在 Web 世界失去了生命力。相反，它找到了最适合自己的利基市场：强调速度和性能的场景。

全球开源咨询公司 Igalia 软件工程师 Andy Wingo 提到，他最近刚刚为某受众庞大、基于浏览器的电子表格做了一个项目。在此项目中，他希望“提高 JavaScript 与 Wasm 之间的字符串转换效率。”在他看来，这类项目属于“大型利益相关方与浏览器开发商间的一对一合作”，也是 Wasm 最常见的应用环境之一。

这也再一次提醒我们，虽然新兴技术总能引发炒作热情与激烈讨论，但其最终命运仍然要由非常具体的用例来决定。

Wingo 还提到，Fastly 和电子商务平台 Shopify 等企业也在使用 Wasm，而这两家公司之所以选择 Wasm，是因为供应商们喜欢用。“所以，推广 Wasm 的力量之源并不是用户，而是先由平台所有者的意愿决定，再一步步传导至用户群体当中。”

Wingo 的观点跟 McMullen 可谓不谋而合，即：并不是所有平台都支持 Wasm，“之所以无法广泛支持，是因为 Wasm 难以嵌入。而导致难以嵌入的原因之一，就是 Wasm 缺乏标准的交互模型。”

因此，尽管大家普遍对 Wasm 的速度和性能优势赞不绝口、给予关注，但在实际应用方面仍存在很大的争议甚至是分歧。

局外人眼中的 Wasm

对局外人来说，Wasm 是种相当奇怪的语言。

首先，这种语言最初的用途定位跟后来真正让它声名鹊起的用例几乎没有关系，但在脱离浏览器的过程中，Wasm 也确实变得更加流畅灵活。于是问题来了：现在的 Wasm，还是当初设想的那个 Wasm 吗？

也许正是存在这个问题，才导致 Wasm 在标准制定方面遭遇困境——由于缺乏明确的共识，不同群体都在朝着自己心中正确的方向发力。

这对用户和潜在的 Wasm 开发者来说当然不是好消息。Wingo 表示，“人们其实都或多或少知道 Wasm 的一些特性，只是不清楚为什么会这样。”

但这也未必是坏事，反而凸显出 Wasm 面临的最大挑战，即如何将其在浏览器中安全高效运行任意代码的能力在制定项目中成功应用。只要解决这点，Wasm 必然能够一飞冲天。

Spencer 对此表示赞同，并在采访中坦言大多数尝试 Grain 的用户其实是想借此探索 Wasm。其实很多用户都“愿意在 Wasm 当中做一些尝试”，只是发现跟 Rust 或 C++等其他语言相比，Wasm 真的让人望而生畏。

虽然编程语言的实质就是帮助人们触及那些无比复杂的逻辑和事物。但有趣的是，Scott Logic 调查给出的数据，其实跟 Spencer 的观点相互矛盾：

在将 Rust 与 Wasm 结合使用的开发者当中，有 24%的受访者表示未来想要试试 Grain。而在其余的调查参与者当中，只有 7%的受访者表示有意尝试 Grain。

看起来，虽然 Grain 是专门为了降低 Wasm 门槛而生，但有能力解决复杂工程问题的人们也完全不抗拒这种更简单的方法工具。

Grain 项目的主页上写道：很多语言都有着绝佳的设计思路，但最终却因为过于深奥难学而致人放弃，无法建立起庞大的技术社区。Grain 希望为这些思路带来新的活力，通过易于使用、理解的方式加以呈现。

这么看来，Grain 存在本身也许正是 Wasm 生态系统的最大短板——这证明 Wasm 没能用简单易行的方法，帮助开发者们了解如何用它解决问题。

互联网上关于这个问题的讨论很多。

在 Quora 上，IT 支持软件厂商 Licorice 的 CTO Julian Jensen 就回答了 Wasm 是否难以上手的问题。

“这个主题下的几乎每篇文章，都涉及如何在浏览器中加载和执行某些非常简单的功能。” “这类回答着实没有营养。它们无法反映大家在现实开发中遇到的问题，也没能触及严肃项目中可能遇到的任何痛点。”

Jensen 的看法可能有些偏激，但他的基本判断是对的：虽然很多人都对 Wasm 抱有兴趣，但 Wasm 的生态系统始终没能提供一种简便易行的学习方式。

更重要的是，这也凸显出 Wasm 面临的一大核心挑战：如何在帮助广大开发者降低理解门槛的同时，确保 Wasm 自身的很多特性不致因过度简化而失去意义？

WebAssembly 组件模型

于是问题又回到了标准化上。没有标准化，我们就永远无法把大肆宣扬的各种技术期望变成现实。目前，最有前途的方案就是 WebAssembly 组件模型。

根据 Spencer 的说法，就是因为负责这项工作的小组始终达不成共识，才“真正阻止了……Wasm 的全面崛起。”McMullen 也回应了这种说法，表示组件模型对于保障“标准交互模型”至关重要，甚至直接决定着 Wasm 能得到多少支持。

组件模型的意义在于简化 Wasm 在浏览器以外的使用方式。通过为不同事物间的协同运行编写出规则和规范，组件模型应该能够消除 Wasm 实际应用中的不少认知负担（和额外代码）。

“组件模型的关键，是让代码得以跨语言和生态系统实现安全高效共享与连接。除此之外，组件模型还有望帮助 Wasm 建立起睽违已久的代码公开接口。只有通过更高级的方式定义这些接口，我们才能就跨语言和平台的工作模式和标准达成一致。”McMullen 表示。

尽管组件模型对整个 Wasm 项目都具有重要意义，但 W3C WebAssembly 社区小组仍在讨论其中的具体细节，而且整个过程可能还需要一些时间。

Spencer 注意到，尽管大家的出发点都是好的，但由于民主化程度过高，人们其实是在相互内耗、把大量时间浪费在了对于小细节的争论上。

那么，距离最终定稿还有多久？Spencer 表示，他觉得具体实施可能要等到 2023 年春季去了。McMullen 则强调，目前的延误其实有其道理：

“大多数工业标准都不及 Wasm 及其配套标准那么严格。这里需要极其精确的措辞，并最终以数学形式编写，这样才能对其正确性做出强有力的证明。” “特别是组件模型，它要做的是定义一项标准，借此跨越多种语言、异步模型、线程模型和行业，同时保持极高的运行效率和安全水平。”

尽管进展缓慢，但 Spencer 和 McMullen 对这项工作的重要意义都给予了充分肯定。Spencer 坦言，Wasm 的命运由工具链决定，毕竟开发者最关心的就是一种语言有没有完备的工具链。

Wasm 会落入专有陷阱吗？

脱离浏览器之后的 Wasm，其未来命运似乎就取决于组件模型能否一战成功。但在此之后，Wasm 还须着眼于更广泛的软件市场。

Wingo 预计，届时会有风险投资入驻这个领域，其中一些可能愿意遵循标准，但也有一些可能想让 Wasm 走向专有锁定。

也许 Shopify 和 Fastly 等公司的当前贡献，就是在为后续的专有演变做铺垫。唯一的问题就是，供应商们能不能把 Wasm 轻松打包成边缘计算解决方案。只要 Wasm 项目的开发门槛不高，就会有更多工程师熟悉这项技术，最终影响供应商对于 Wasm 类方案的设计思路。

而且 Bytecode 联盟也未必就有垄断 Wasm 的想法。McMullen 更愿意将联盟视为 Wasm 的“元生态系统”。“我们绝不会在 Wasm 之内搞一言堂。我们所需要的不只是一种语言，更是多样性的平台和行业。”

结束语

无论风险投资方们怎么谋划、无论项目各种 fork 背后的核心开发团队选择哪条路线，Wasm 本身永远是一项重要且极具价值的技术，完全有能力在正确的场景下改变游戏规则。

所以，最大的难题其实就是，怎么按捺住激动的心、颤抖的手，忍着别把 Wasm 的影响力和价值抽象化成特定某一种软件工程工具。

Spencer 强调，归根结底，Wasm 只是一种编译器目标、一种实现细节。如果 Wasm 能在未来几年内把自己的问题解决好，那它就会从流行词转化为润物细无声的开发方式。

这样的未来看似简单，也是 Wasm 最合理的发展目标。但纵观整个发展历程，要让这个目标真正落地，还需要解决大量争论、探索、实验和共识。

参考链接：

https://thenewstack.io/whats-stopping-webassembly-from-widespread-adoption/

https://devclass.com/2022/09/29/massive-web-tech-survey-shows-how-bad-habits-continue-and-webassembly-may-be-over-hyped/?td=rt-3a