《WebAssembly 权威指南》（1）WebAssembly 简介

本文是《WebAssembly 权威指南》系列文章第一篇，系列文章列表：

• 《WebAssembly 权威指南》连载公告
  

非凡的主张需要非凡的证据。

——Carl Sagan 博士

本章将介绍 WebAssembly 及其诞生的背景。从某种意义上说，它是过去七十年来 Web 发展的巅峰。我们有相当多的历史要介绍。如果你不喜欢历史论述可以跳过这一章，直接去看第二章，但我希望你不要这样做。理解为什么这项技术如此重要以及它的起源是很重要的。

WebAssembly 提供什么

我认为工程师最伟大技能就是能评估新技术可以带来什么。正如北卡罗来纳大学的 Fred Brooks 博士（译者注：《人月神话》作者，2022 年去世）提醒我们的那样，没有什么 "银弹"^[1] 所有的东西都是有取有舍的。复杂性往往不会因为一项新技术而被消除，而只是被转移到别的地方。因此，当某些东西确实带来改变或引导我们工作方式朝向积极方向时，值得我们关注，我们应该弄清楚原因。

当我试图理解某项新事物的含义时，我通常会先试着确定其背后的动机。洞察力的另一个良好来源是替代方案的不足之处。以前有什么，它是如何影响我们试图破译的这项新技术的？就像艺术和音乐一样，我们不断地从多个来源借鉴好的想法，所以要真正理解为什么 WebAssembly 值得我们关注，以及它所提供的东西，我们必须首先看看它之前都有什么，以及如何发挥作用的。

在正式向世界介绍 WebAssembly 的论文中，作者指出，其动机是为了满足现代 Web 交付的需求，在软件方面的应用，单靠 JavaScript 是无法做到的。归根结底，这是一个提供软件的追求，即：

• • 安全

• • 快速

• • 可移植

• • 紧凑

在这个愿景中，WebAssembly 的中心是软件开发、Web、Web 的历史以及它如何在地理分布空间中提供功能的交叉点。随着时间的推移，这个想法已经大大超出了这个起点，想象出一个无处不在的、安全的、高性能的计算平台，几乎触及我们作为技术专家的职业生活的每一个方面。WebAssembly 将影响客户端 Web 开发、桌面和企业应用、服务器端功能、传统现代化、游戏、教育、云计算、移动平台、物联网（IoT）生态系统、无服务器和微服务等领域。我希望在本书中能让你相信这一点。

我们的部署平台比以往任何时候都更加多样化，因此我们需要在代码和应用层面上的可移植性。一个通用的指令集或字节码目标可以使算法在不同的环境中工作，因为我们只需要将逻辑步骤映射到它们在特定机器架构上的表达方式。程序员们使用应用程序编程接口（API），如 OpenGL、 POSIX 或 Win32 ，因为它们提供了打开文件、拉起子进程或在屏幕上绘制的功能。它们很方便，减少了 开发人员需要编写的代码量，但它们对提供功能的库存在依赖性。如果 API 在目标环境中不可用，应用程序将无法运行。这是微软能够利用其在操作系统市场上的优势，也是其在应用程序套件中占据主导地位的方法之一。另一方面，开放标准可以使软件更容易移植到不同的环境。

软件运行时另一个问题是，不同的主机有不同的硬件能力（CPU 核心数量，是否有 GPU）或安全限制（是否可以打开文件或发送和接收 Web 流量）。软件往往通过使用功能测试方法来适应现有的东西，以确定一个应用程序可以利用哪些资源，但这往往会使业务功能复杂化。我们根本无法承担为多个平台不断重写软件所需的时间和金钱。相反，我们需要更好的重用策略。我们还需要这种灵活性，而不需要修改代码以支持它将运行的平台的复杂性。为不同的主机环境编写不同的代码会增加其复杂性，使测试和部署策略变得复杂。

经过几十年的发展，开源软件的价值主张已经很清楚了。我们倾向于使用由其他开发者编写的有价值的、可重复使用的组件，以此来满足我们自己的需求。然而，并非所有可用的代码都是值得信赖的，当我们执行从互联网上下载的不值得信赖的代码时，我们就会受到软件供应链的攻击。通过 Web 钓鱼攻击、数据泄露、恶意软件和勒索软件，我们容易受到不安全的软件系统的风险、商业影响和个人成本的影响。

直到现在，JavaScript 一直是解决其中一些问题的唯一方法。当它在沙盒环境中运行时，它给了我们某种程度的安全。它是无处不在的，可移植的。引擎已经变得更快。生态系统已经爆炸性地成为生产力的雪崩。然而，一旦你离开了基于浏览器的保护范围，我们仍然有安全问题。作为客户端运行的 JavaScript 代码和在服务器上运行的 JavaScript 是有区别的。单线程设计使长期运行或高度并发的任务变得复杂。由于它起源于一种动态语言，有几类优化可以用于其他编程语言，而这些优化现在和将来都不能作为最快和最现代的 JavaScript 运行时的选项。

此外，增加 JavaScript 的依赖性太容易了，而没有意识到其中存在多少包袱和风险。开发人员如果不花时间仔细考虑依赖性风险，最终会给上游软件测试、部署和使用的各个方面带来麻烦。每一个脚本一旦在 Web 上传输，就必须被加载和验证。这就延长了加载时间，使得一切都感觉很迟钝。当一个依赖包被修改或删除时，它有可能扰乱大量的部署软件。

在有些观察者眼中 WebAssembly 是对 JavaScript 的攻击，但事实并非如此。当然，如果你愿意，你可以避免使用 JavaScript，但它主要是为你提供选择，用你选择的语言解决问题，而不需要一个单独的运行时，或不得不关心另一个软件是用什么语言写的。现在已经可以使用 WebAssembly 模块而不知道它是如何构建的。这将增加我们从软件中获得的商业价值的寿命，同时允许我们在采用新语言时进行创新，而不影响其他部分。

在过去的几十年里，我们经历了几个试图解决这些问题的工具、语言、平台和框架，但 WebAssembly 第一次把它做对。它的设计者并没有试图过度规范什么。他们正在从过去的经验中学习，拥抱 Web，并将问题空间的思维运用到最终是一个困难的多维问题上。在我们进一步深入研究之前，让我们看看对这一令人兴奋的新技术的形成性影响。

Web 的历史