人们使用 WebAssembly 构建什么？

WebAssembly（WASM）在过去几年里一直是个热门词。这项技术虽然备受关注，但在实践中应用却并不广泛。我一直对它的现状感到好奇，因此我调查并总结了一些发现。其中一些发现可能会让你感到惊讶。

背景

在 WebAssembly 标准出台之前，JavaScript 是 Web 浏览器唯一支持的编程语言。然而，WASM 从未被设计为 JavaScript 的替代品，而且由于 JavaScript 过于底层，WASM 也无法替代 JavaScript。相反，WASM 是专门为补充 JavaScript 而设计的，旨在解决 JavaScript 在执行计算和内存密集型任务（例如视频编辑、游戏、CAD 等）时的性能问题。

但是，随着它的发展，一些有趣且意想不到的副作用场景也随之出现，正如您将在本文中看到的那样。

在我们继续之前，有几点需要注意：

• 您无需直接编写 WASM。相反，您可以使用 C++ 或 Rust 等高级语言并将其编译为 WASM。
• 它以紧凑的二进制格式（如机器码）存储。
• 它在安全、隔离的沙箱中执行。
• 它本身除了快速处理大量数据外，功能不多。它不需要网络、文件系统，也不支持 DOM 访问。

人们使用 WebAssembly 构建的内容可以分为两类：在浏览器中和在服务器上。

在浏览器中

人们在浏览器中使用 WebAssembly 主要有三个原因：

1. 优化计算和资源密集型任务的性能。
2. 将旧版本机应用程序迁移到 Web 应用程序。
3. 允许在浏览器中运行 Javascript 以外的语言。

让我们来探讨一下这些用例的一些重大成功案例。

Figma

如果你是一名 UI/UX 设计师，或者是一名时不时会修改设计的开发者，那么你过去一年里一定不能错过 Figma。这是一款非常棒的产品，展现了如今 Web 应用所能达到的顶尖性能。

WebAssembly 是 Figma 成功的秘诀之一。令许多人惊讶的是，尽管 Figma 是一款 Web 应用，但它的编辑器却是用 C++ 编写的，这甚至在 WebAssembly 出现之前就已经存在了。考虑到浏览器只能执行 JavaScript，这怎么可能呢？答案很简单：C++ 代码在交付到 Web 之前会被编译成 JavaScript。

但为什么不从一开始就使用 JavaScript 呢？关键的区别在于如何将 C++ 代码转译成 JavaScript。JavaScript 是一种非常动态的语言。为了提高其运行速度，浏览器引擎会进行大量的动态优化。然而，结果仍然不够理想且难以预测。有一种方法可以提高 JavaScript 的性能——像使用静态语言一样编写代码，以便引擎更容易处理。Figma 最初使用“asm.js”来实现这一目标——它本质上是一个将 C++ 代码高效地转换为 JavaScript 代码的转译器。

然而，最终它仍然是 JavaScript 代码，通过网络加载时不够紧凑，浏览器仍然需要解析其文本。这正是 WebAssembly 优于之前方法的地方。WASM 是一种面向机器的代码。它比 JavaScript 更紧凑，浏览器的处理成本也更低。通过从 asm.js 迁移到 WebAssembly，Figma 的性能提升了 3 倍。

AutoCAD

AutoCad 诞生于 1982 年，其历史比 Web 还要悠久，而且规模庞大——它拥有多达 1500 万行 C++ 代码。AutoCad 一直想迁移到 Web 平台，但用 JavaScript 重写所有内容并不实际：工作量巨大，而且最终产品速度慢得多。最终，WebAssembly 应运而生。

AutoCAD 对 WebAssembly 的使用在很多方面与 Figma 相似，只是它还有一个额外的问题，那就是需要解决对 Windows 操作系统的紧密依赖。然而，令人惊讶的是，WebAssembly 作为一项相对较新的技术，竟然能够支持如此庞大而复杂的应用程序，并在现代社会赋予它全新的面貌。

顺便说一句， Adobe Photoshop 也在WebAssembly 的帮助下迁移到了 Web 上。

微软 Blazor

Blazor 是微软推出的一款基于其主要后端语言 C# 和 WebAssembly 开发 Web 前端的工具。正如其口号所说，Blazor 的目标是构建无需编写 JavaScript 的全栈 Web 应用。但为什么呢？原因可能是微软的开发者们太喜欢 C# 了，想把它用在任何地方。

// A Blazor component
@page "/counter"

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

// C# below
@code {
    private int currentCount = 0;

    [Parameter]
    public int IncrementAmount { get; set; } = 1;

    private void IncrementCount()
    {
        currentCount += IncrementAmount;
    }
}

熟悉微软生态系统的人可能会立即问：这是 Silverlight 的复兴吗？不，不是。Silverlight 是一项专有技术，需要安装，并且不支持通用浏览器。相反，Blazor 基于 WebAssembly，而 WebAssembly 现已成为 Web 标准的一部分。

虽然 Blazor 的价值主张略显奇怪，但它出色地展现了 WebAssembly 为浏览器引入更多编程语言的潜力。我认为这样的努力不会威胁到 JavaScript 的统治地位，但在某些有趣的小众场景中，Blazor 确实非常有用。例如，直接在浏览器中运行 Python，你就可以在不运行本地 Python 服务器的情况下使用 Jupyter Notebook：

在服务器上

WebAssembly 的创造者在创建这项技术时可能已经考虑到了在非浏览器环境中运行的可能性，但服务器端开发人员的热情远远超出了他们的预期。

这种兴奋是可以理解的——WebAssembly 提供了一种在服务器上执行不受信任代码的理想方式——它可移植、更易于保护、比 JVM 或 Docker 占用更少的内存，并且是许多高级语言的自然编译目标。对于托管在您的 IDC 中的长期运行的 Web 服务器进程来说，它可能意义不大，但在某些场景下却大有裨益：

• 无服务器托管提供商需要为其租户大规模运行短期例程 - 快速启动、低占用空间和沙盒至关重要。
• 支持运行用户或社区提供的插件的 SaaS 产品
• 资源非常紧张的边缘环境

WASI规范的诞生开启了服务器端 WASM 的蓬勃发展。WASI 是 WASM 的一个对等规范，旨在标准化 WASM 代码与其托管环境的交互方式。在浏览器中，这并非必要，因为 WASM 是对 JavaScript 的增强，而 JavaScript 已经可以通过 DOM、BOM 和 Web API 访问其托管环境（浏览器）。而在服务器上，WASM 是独立的，如果它无法与其环境交互，那么它的作用就不大。

如果您对现实世界的进展感兴趣，请查看以下将服务器端 WASM 封装到服务中的公司。随着技术的成熟，它们可能会成为传统基于容器的 PaaS/FaaS 供应商的强劲挑战者。云计算行业长期以来一直渴望一个小型、可移植、安全的应用程序运行时。

宇宙

费米子

Cloudflare WASI 支持

宣布 Cloudflare Workers 支持 WASI

今天，我们宣布在 Cloudflare Workers 上对 WASI（WebAssembly 系统接口）进行实验性支持，并在 wrangler2 中提供支持，以使其使用起来更加愉快。

blog.cloudflare.com

下一步

WebAssembly 仍是一项新兴技术。在浏览器端，用例已经非常成熟。然而，它仍需要发展成为一种更易于开发的工具——目前，你无法像 ES 模块那样直接加载 WASM，需要复杂的 JavaScript 粘合代码来与之交互。在服务器端，它甚至更加不成熟，其价值也存在争议。它正在等待行业巨头的押注，加速其普及。

看看 2023 年 WebAssembly 将如何进一步突破 Web 开发的界限，这将会很有趣。

附言：我们正在构建ZenStack——一个使用 Next.js + Typescript 构建安全 CRUD 应用的工具包。我们的目标是让您节省编写样板代码的时间，专注于构建真正重要的内容——用户体验。