这篇文章是我们的直播的摘要,其中Flaki带我参观了 WebAssembly 生态系统。谢谢你,弗拉基!

WebAssembly(或简称 Wasm)之所以重要,原因有很多。使其成为一项引人注目的技术的因素之一是,作为标准,是如何来自一个委员会并由它开发的,以及它的生态系统是如何从该理念演变而来的。在这次讨论中,我们审视了生态系统本身并思考了它的未来。

开始:在网页上运行代码

Wasm 最著名的用途之一是它在 Web 上的应用程序,例如在浏览器中运行 DOS 游戏(由 Internet Archive 提供)或图像处理。

Internet Archive 对 DosBox 的使用让人们可以在由 WebAssembly 提供支持的浏览器中玩经典的 DOS 游戏。这是通过将开源 DOS 模拟器DOSBox引入网络来实现的。

但正如运行中的噱头所说:WebAssembly 既不是 Web,也不是 Assembly——也就是说,严格来说,它不仅仅是一种像 Assembly 编程语言这样的语言,而是虚拟机的定义,并且从一开始它就立志远超这个范围的网络。

我们是怎么到这里的?

WebAssembly 被构建为一系列密切相关但又相互独立的标准,发布在官方网站上,用于技术。 WebAssembly 社区中的个人和组织,例如字节码联盟正在继续合作以维护和进一步推进这些标准。

字节码联盟的网站,描述了其对开放 Wasm 标准的贡献。

.wat和binary文件

虽然可以将几种编程语言编译为 Wasm,但该字节码需要以自己的方式运行,使用Ahead-of-Time(AoT) 或Just-in-Time(JiT) 编译器,每个编译器都有自己的超出本文范围的优点和缺点,我们将尝试专注于 Wasm 生态系统。如需进一步了解 JiT 和其他编译器,请查看这篇有用的博客文章!

但是,WebAssembly 在文件系统或代码中是什么样子的?两种使用的格式是二进制.wasm文件格式和.watWebAssembly 文本格式。两者都等同于用其他语言编写的源代码的目标表示,旨在用作 WebAssembly。也就是说,虽然两者都可以编译为机器原生字节码,但.wasm二进制文件也可以在大多数运行时直接执行。两者之间的另一个区别是.wat具有更易于人类阅读的好处。诸如 WasmFiddle 之类的 Playground 允许我们在浏览器中查看这两种表示并检查我们的 Wasm 输出文件的样子:

WasmFiddle 显示了一个 C 程序,该程序返回被编译为 Wat 格式的数字 42。

基于标准的可能性

最近的一个重要扩展是 WebAssembly 系统接口,或WASI标准。正如该网站所描述的,它的重点是在 WASI 中运行的程序的安全性和可移植性,这些程序旨在独立于 Web API、JavaScript 或浏览器运行。这种从浏览器中解脱出来的方式对 Wasm 的下一步发展有着巨大的影响。

代码复用性

能够将模块捆绑到可以在不同应用程序之间共享的 Wasm 二进制文件中,例如libSquoosh用于执行图像处理的不同应用程序,甚至是同一应用程序的不同版本,例如Google Earth在桌面和网络上。

作为 Squoosh 应用程序的一部分,libSquoosh 可作为 JavaScript 应用程序的单一集成使用。

Google 地球,用 C++ 编写,在浏览器中运行,代码与在桌面上运行的代码相同。

容器化:服务器上的 Wasm

拥有可以内置应用程序及其依赖项的独立于平台的 WebAssembly 字节码有助于提高它们的可移植性。

这为 WebAssembly 的最新和最激动人心的发展之一打开了大门:在服务器上运行。这是在Shopify等地方完成的,以扩展他们的应用程序,Cloudflare Workers实现无服务器代码的部署,以及我们自己的开源云原生 WebAssembly 框架Atmo。

CloudFlare Workers 的网站,吹嘘他们能够发布小段可运行代码。

扩展性和安全性

WebAssembly 的沙盒优先计算方法允许用户创建可扩展和安全的环境,人们可以在不影响安全性的情况下开发他们喜欢的应用程序的插件和扩展,例如Figma 的插件系统。

然而,凭借 WASI 的强大功能,我们不仅限于浏览器。在桌面端,Wasm 也很能干!例如,终端多路复用工具Zellij拥有在 WebAssembly 上运行的插件的能力。

Zellij 的用户文档,描述插件系统。

超越浏览器和桌面

Wasm 提供的安全性和可扩展性甚至超越了浏览器和桌面,因为它在云中也非常有用。

在 Suborbital,我们正在利用服务器端 Wasm,允许人们扩展他们的 SaaS 应用程序以提供无服务器功能并利用 WebAssembly 的完全可扩展性和性能优势。

这也是 Shopify 通过其应用商店所做的事情,使开发人员能够开发与 Shopify 直接交互的第三方应用程序,在 Shopify 的基础架构中执行以减少与自托管应用程序相比的延迟,同时利用 WebAssembly 的安全性。

容器化带来边缘计算

WebAssembly 的原则顺利地转化为边缘计算用例,即更接近向服务发出请求的客户端的复杂代码执行。 Wasm 二进制文件可以轻松构建并部署到边缘节点,并且它们能够在这些不太强大的环境中高效运行。

边缘计算的不同应用包括用于复杂 Web 应用的服务器端渲染 (SSR) 和无服务器 SaaS 功能。通过使用 WebAssembly,我们可以反过来利用它的安全性和可移植性,还让人们有机会用熟悉的编程语言编写可编译为 Wasm 目标的编程语言。

https://en.wikipedia.org/wiki/Edge_computing#/media/File:Edge_computing_infrastructure.png。

那么为什么要在虚拟机之类的东西上使用它呢?不同之处在于前面概述的沙盒因素。虽然 VM 需要以零碎的方式锁定内核空间,但在 Wasm 中,这被视为“默认拒绝”系统,让我们作为开发人员或管理员来明确定义要启用的 WASI 或其他 WebAssembly 权限。

拥有这些快速初始化、内存高效、安全的 Wasm 二进制文件使我们能够在微秒而不是毫秒的时间内运行这些类似进程的微小计算。

Fastly 的 Compute@Edge 平台。

未来会怎样?

WebAssembly 中最令人兴奋的发展之一是纳米过程模型的形式。通过标准化各个 Wasm 模块之间的接口(独立于模块最初编写的编程语言),我们可以从以轻量级方式链接的 WebAssembly 模块组成复杂的应用程序,从而提高安全性、可重用性并进一步提高开发速度。

Wasm 纳米过程如https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/中所示

这种微流程模型绝对值得关注!它以及规范的其他扩展及其实现将继续推动 WebAssembly 生态系统向前发展,我们渴望看到它的发展方向。

嘿,为什么不结束一些有趣的事情呢?如果我们可以在浏览器中运行 DOS 游戏,这个概念是否可以提高到 11,比如在浏览器中运行整个计算机架构?

在浏览器中运行纸牌游戏的 Windows 98:https://copy.sh/v86/?profileu003dwindows98。

事实证明,是的,它可以。在这里,我们不只是运行 DOS 模拟器,而是在 WebAssembly 中模拟运行 Windows 98 的计算机的整个架构。挺酷的!