WASM：计算的未来还有多远？

导读：在涉及到 WebAssembly（WASM）的未来前景时，不同的观点和声音交织在一起。虽然取得了许多重要进展，但也有声音指出在可靠高效地支持生产用例方面仍有很多工作要做。这种多元的看法不仅仅存在于个别观点中，分析师 Torsten Volk 也持有类似的观点。当然，还有其他经验丰富的专业人士表达了截然不同的看法。在这个引人入胜的讨论中，我们将探讨不同观点，并深入了解 WebAssembly 的潜力和挑战。

WebAssembly 正在受到广泛关注，但它是否真的能像一些人所期望的那样颠覆游戏规则呢？

有人如此评价：自 1995 年起，JavaScript 作为 Web 脚本编程的翘楚已经历数十年风雨。虽然其才华横溢，但 JavaScript 在处理性能密集任务时亦有局限。随着 Web 发展，对 Web 应用程序功能、速度和灵活性的需求也与日俱增。因此，WebAssembly （WASM）应运而生。

为满足在 Web 浏览器中运行代码的高效需求，万维网联盟（W3C） 和主流浏览器厂商联手研发新型二进制格式。该格式旨在快速、高效且安全，使开发人员能以接近本地速度运行代码。因此，2015 年，WebAssembly（WASM）作为一种低级虚拟机问世，执行从高级语言翻译而来的字节码。如今，WASM 并不是编程语言，而是一种紧凑的二进制指令格式。与解释执行的 JavaScript 不同，WASM 为一种低级字节码，在浏览器内部的沙盒环境中运行，确保速度与安全。

开发人员热衷使用 WebAssembly，因为它让他们能以熟悉的编程语言如 C、C++ 和 Rust 编写代码。Web 开发人员也对此感到满意，因为他们无需替换 JavaScript 程序，而是能够从 JavaScript 中调用 WASM 函数，反之亦然，实现了两者之间的无缝集成。

起初，WASM 只用于 Web 领域。然后情况发生了变化。2019 年，Mozilla 推出了其 WebAssembly 系统接口（WASI）以访问操作系统资源。这使 WebAssembly 脱离了浏览器的限制。

一旦摆脱了浏览器的限制，就像 WASM 专家和 Fastly 工程总监 Lin Clark 所说，它成为了一种 “在所有机器上运行相同代码的快速、可扩展、安全的方式”。

听上去耳熟能详，是吧？你可以用相同的描述来描述容器。但你不必全然相信。正如 Docker 的联合创始人 Solomon Hykes 当时在推文中所言：“若 WASM+WASI 早在 2008 年就存在，我们便无需创立 Docker 了。其重要性不言而喻。服务器上运用 WebAssembly 乃是计算的未来所在。而标准化的系统接口则成为缺失的一环。”

最近，2023 年，云原生计算基金会（CNCF）生态系统负责人 Taylor Dolezal 指出：“WebAssembly 是未来趋势，因为其在无服务器、容器化和插件技术中的应用不断增多，预计将对 Web、无服务器、游戏和容器化应用产生深远影响。”

言之凿凿。那么，WASM 是否将成为 “计算的未来”？

从个人角度来看，Steven J. Vaughan-Nichols 一直对此心存疑虑。虽然诸如 WASI 之类的程序以及竞争对手运行时（如 WasmEdge）已经大大简化了在边缘和后端运行经过优化的 WASM 代码，但 Steven 认为仍有很多工作要做。而且，他并非唯一看到这个问题的人。

正如企业管理协会分析师 Torsten Volk 所言：“在可靠高效地支持生产用例方面还有很多工作要做。”确实如此。

举个例子，Python 已经成为人们快速、轻松处理机器学习程序的首选方式，这要归功于 PyTorch。然而，将这些程序简单地放入 WASM 运行时并期望它们顺利运行是不现实的。问题在于，你还需要许多目前尚未支持的第三方依赖项。

随着 WASM 受欢迎度的提升，公司和开源社区将需要承担起构建这些基础设施的艰巨任务。

然而，你可能会提出疑问——Kubernetes 难道不是未来吗？是的，但正如 Adobe 最近指出的，WASM 和 Kubernetes 可以合作共存。他们找到了一种方法，使一个 “完整的微服务，目前在 Kubernetes 中运行，也可以在 WASM 中运行”。

这样做的原因何在？这为他们带来了一种更轻盈的模型，能够在流量激增时迅速扩展，相较于粗粒度容器更具调度灵活性，同时仍然借助 Kubernetes 进行编排。对 Adobe 而言，这是两全其美的完美选择，兼顾了两者的优势。

虽然 Adobe 拥有比大多数公司更多的资源来解决这些问题，但展望未来，对于规模较小的企业来说，WASM 或许会变得更加适用于后端。

这得益于 WebAssembly 组件模型（WACM）和 WASI-Preview 2 的存在。

WACM 项目将逐步定义一个组件模型，它将为从 WASM 核心模块构建的、具有可移植性、加载和运行效率高的二进制格式提供支持，从而实现了可移植性强、跨语言组合的能力。它还将更好地支持可虚拟化、静态分析、能力安全和与语言无关的接口。

WASI-Preview 2 是 WASI 的下一个版本，它将扩展 WASI 的 API，不仅包括 POSIX，还包括 WASI 文件系统、HTTP、云和网络套接字。它还将提供更好的绑定支持非 C 类语言。

总而言之，Steven 认为 WASM 最终可能充分释放其潜力。然而，在开发人员的构想与实际生产代码之间仍然存在诸多挑战。不过，已经奠定了构建实际 WASI 后端设计所需的基础。到了 2025 年，我们将揭晓 WASM 是否确实能成为后端软件开发的未来。

在著名的技术论坛 Hacker News，也有很多大佬对 WASM 的未来发表了各自独到见解。InfoQ 精选如下：

网友 ivanmontillam 对 WASM 的期望和对 Javascript 在前端开发中的挑战有深刻的认识，他认为 WASM 有望提供一种更灵活、更容易处理多种技术栈的方式，从而摆脱 JavaScript 的统治地位。他的观点强调了对 Web 开发的包容性和多样性的重要性。

ivanmontillam：

我对 WASM 获胜充满期待。在前端 Web 开发中，我一直对 JavaScript 的怪异之处感到沮丧。它充满了陷阱，对于新手来说很难调试，除非你在入门之前学习了一门正规的 JavaScript 课程，告诉你在遭受陷阱之前要小心。除了 JavaScript，我从未遇到一种编程语言在初次接触时没有按照我期望的方式运行。

 

我深知 TypeScript 的存在，也明白转译器的优势，其语法（现代 ECMAScript）和规则更适应时代。然而，它们并非浏览器的 “原生” 部分，仍需转译成危险的旧 JavaScript。虽然转译器能避免许多陷阱，但我仍感觉自己在沙地上建造摩天大楼。

 

关于这个话题的难点在于，我确信我的评论会触怒许多开发人员，因为这样谈论 JavaScript 会让人感觉我侮辱了他们的信仰。澄清一下，我无意如此。我来自静态类型编程语言的世界，所以我更倾向于我的编程是最正确的。

 

对我来说，假设我们能创建一个主要执行虚拟机不是 JavaScript 的浏览器，WASM 将提供坚实的基础。我梦想拥有一个支持多种技术栈的浏览器，摒弃 HTML/CSS/JavaScript 的垄断。为何不考虑类似 HTML/CSS/Python 的选择呢？

 

对我而言，JavaScript 在职业发展上已成为一种挫败因素。尽管我在后端 Web 开发方面表现出色，但我深信并非只有我一个人对 JavaScript 感到沮丧。Web 应该更加包容。

网友 Phil_kahrl 对 WASM 赞赏有加，尤其在与 JavaScript 相较之下。他盛赞 Rust 与 WASM 的强强联合，以及 Cargo 作为出色的包管理器，使他的项目依赖管理更加得心应手。他还强调了 WASM 捆绑包的潜在大小优势，以及使用 Rust 进行低级操作的便捷性。最重要的是，他认为使用 WASM 编写的应用程序比 React 编写的应用程序更迅捷，尽管这一点也与所使用的框架（Leptos）息息相关。这一观点凸显了 WASM 在前端开发的潜力和吸引力。

phil_kahrl：

我坚信 WASM 将胜出。经过 25 多年的 JavaScript 使用，我最近尝试了使用 Rust/WASM 和 Leptos 框架构建一个单页应用程序（SPA），并自此不再想回到 JavaScript。Cargo 作为出色的包管理器，让我的项目静置一两年后再回来构建运行时变得轻而易举，而无需进行大量的依赖更新（与 NPM 相比）。Rust 的坚实类型系统，加上借用检查器和模式匹配，使我能够编写可靠且难以破坏的代码。无需经过多个阶段的 Babel 和 Webpack 构建流程，只需将 Rust 编译为 WASM 目标即可。此外，WASM 捆绑包的大小可能比相应的 JavaScript 捆绑包更小。借助 Rust，在客户端高效地进行低级操作，比如从镜像二进制数据中进行特征提取，也更加便捷。而且，用 WASM 编写的应用程序比我用 React 编写的类似应用程序运行得更快，尽管这主要归功于 Leptos 不像 React 那样使用虚拟 DOM。

网友 jeroenhd 的见解深入透彻，对 WASM 和 JavaScript 的优势与局限进行了剖析，并引发了关于开发工具和开发者教育的重要议题。

jeroenhd：

我倡导在浏览器中运行 TypeScript，但 WASM 只是另一种编译器，就像 TypeScript 一样。无论对转译器的担忧如何，一旦将代码编译成二进制代码块，调试和解决问题都会更加困难。如果信任 Python 解释器，也可以信任 TypeScript 转译器。处理糟糕情况如 IE11 或旧版 Safari 版本时，调试可能复杂，但我们已不再生活在 2010 年。

 

JavaScript 非常不便，有大量奇怪的边界情况（例如，“分号是可选的，除了这三个边界情况”），通过使用进行作用域切换，不可预测的类型转换等。然而，编写一个转译器来处理这些规则并不是那么困难。将另一种语言转译成 JavaScript 可能会放弃一些优化机会，因为需要按照另一种语言期望的方式重新实现方法，而不是直接调用本机 JavaScript API。但至少它具备正常的 API 可供依赖。

 

WASM 就像 Docker，在我机器上工作，但无法让你的机器上工作，所以我们将机器一起打包。你将标准库和 JSON 解析器发送到浏览器，就像推送代码到裸金属服务器上。

 

JavaScript 并不难学，HTML 和 CSS 也不难。然而，许多 WASM 开发者试图在不了解浏览器工作原理的情况下编写浏览器代码，这是糟糕的想法，最终只会导致膨胀或抽象不当。试图将 “后端开发人员变成前端开发人员” 只会带来沮丧的 Java 小程序，几乎无法在桌面浏览器上运行，更不用说触摸屏和手机上了。

 

“本地” 桌面开发之所以演变成 “运行过时的 Chrome 副本并加上一些操作系统胶水”，是因为 Web 开发相较前端开发更容易，尤其需要跨平台支持。WASM 无法让后端开发人员即刻成为前端高手，需学习新框架及难以使用的工具。

 

只需使用 JavaScript，尽管可能有一些不便，但比提出的其他替代方案要好得多。

网友 jillesvangurp 对 WASM 和前端开发提出了一系列深刻见解，强调了 WASM 作为 Web 开发的重要趋势。他讨论了 WASM 对传统观念的影响以及未来的潜力，展示了对 Web 开发领域不断演变和创新的关注。

jillesvangurp：

对于典型的单页应用程序（SPA），其代码库通常会变得混乱不堪，精简的 JavaScript 代码中难以找到透明和可发现的特点。除了少数个别开发人员外，大多数 Web 开发者将浏览器中的 JavaScript 视为一种编译目标。

 

WASM 不过是更为出色的编译目标之一，更具通用性、易于优化、更紧凑，同时还支持逐步加载等特性。若必须编译代码，则最好选择适合的编译目标。

 

广泛而言，我认为 WASM 开始挑战束缚了 Web 开发者二十年之久的传统观念，即 “只能使用 DOM/CSS/JavaScript”。虽然这在过去是唯一可行方案，但移动应用开发者和游戏开发者更倾向于本地开发，因为 Web 开发技术一直表现不佳。设计师追求理想效果的同时，Web 的能力一直受限。我们曾尝试过 Flash、Shockwave 和 Silverlight 等替代方案，但 HTML5 未能完全替代它们，而由于安全原因，浏览器插件逐渐被废弃，但我们始终未找到理想的替代品。

 

现在，有了 WASM，我们不再有理由坚守传统的 DOM/CSS/Javascript 技术。如果愿意，可以使用这些技术，但现在有了其他选项。尽管目前仍需要使用 C++ 和 Rust 等语言，但 WASM 正在迅速发展。

 

WASM 正处于迅速成熟的过程中，浏览器中一些功能标志（例如新的垃圾回收功能）正在后台开发中。一旦这些标志得到移除，WASM 的地位将更加平等。从那时起，主要的挑战将是 UI 框架和工具链需要适应这一新现实。实际上，Jetbrains 正在积极开发基于 WASM 的多平台 UI 框架 Compose，该框架可以渲染到画布上。尽管仍处于实验阶段且需要在浏览器中设置一些功能标志才能运行，但它允许开发人员使用 Compose 进行跨平台 UI 开发，支持 Android、iOS（尽管是 alpha 版本）、桌面（基于 JVM），并计划不久的将来支持基于 WASM 的 Web 平台。可能还会有其他一些 UI 堆栈很快开始面向 Web 开发。当然，Blazor 是 WASM 的早期采用者之一，但它使用自己的垃圾回收机制，可能会导致应用程序变得臃肿。

 

总而言之，HTML5 不再是唯一的选择，它必须根据实际情况竞争，而不仅仅是依赖于垄断地位。这些变化反映了 Web 开发领域的不断演进，为开发人员提供了更多选择和灵活性。

网友 jeroenhd 提出的观点强调了 Web 开发领域的一些关键议题，包括调试工具的重要性、新技术的复杂性、性能和用户体验的重要性，以及技术的持续演进对开发者的影响。这些观点促使我们思考如何更好地利用现有工具和技术，并在采用新技术时保持警惕。

jeroenhd：

我一直在使用 Firefox 中的 JavaScript 调试器来修改经过精简的 JavaScript 代码。尽管开发者可能会随意重命名他们的方法，但除非有故意的混淆（在这种情况下，请忽略我的措辞），阅读经过精简的 JavaScript 代码并非难事。事实上，Firefox 甚至内置了一些用于检测常见 Web 框架的功能，这使得与大多数缩小后的代码一起正常工作成为可能。在我接受 WebAssembly 与 JavaScript 一样晦涩难懂的观点之前，我们需要在浏览器中构建一个相当先进的 WebAssembly 反编译工具套件。

 

我对 WebAssembly 作为 Web 应用程序平台以及对明目张胆滥用 <canvas> 元素的趋势感到不满。尽管它旨在为开发人员节省时间，但每次这样的技术出现时，Web 页面都变得更慢、更难以使用。React（Native）多年前就已经实现了跨平台应用程序和 Web 开发的无缝集成，而无需为每个访问的页面下载数兆字节的可执行二进制块。

 

WebAssembly 实际上类似于 Java 小程序和 Flash 嵌入，只是该模式的第四次出现。它们都面临相似的问题，几年后可能导致相同的性能下降和麻烦。对开发人员来说，唯一的不同在于现在可以使用现代语言如 Rust 编写 WebAssembly 模块，且无法禁用加载这些二进制块的功能。

网友 3cats-in-a-coat 对 WASM 提出了合理的质疑，担心其在 Web 开发领域可能面临挑战，特别是在性能和用户体验方面。他强调了在采用新技术时需审慎考虑各种因素，并指出 WASM 或许能解决特定问题，但并非所有问题的唯一解决方案。

3cats-in-a-coat：

你还可以在没有操作系统分裂的情况下运行相同的构建。假设所有 Windows 机器运行相同的构建。所有 iPhone 运行相同的构建（实际上不完全是这样，但假设他们在 App Store 上自动化并高效地隐藏了构建，零工作量）。总的来说，构建不是问题。如果它们成为问题，那是一个分裂的、不成熟的生态系统的症状，而事实上，许多 Linux/BSD 发行版在大局上仍然是如此。

 

然而，所有这些都无关紧要。因为我们有 Java 和无数其他跨平台运行时环境。WASM 充其量只是相同主题的另一种变体，投放到同一个池中。我完全可以理解，虽然人们可以热情地说 WASM 是未来，因为它具有沙箱化和多平台特性。事实是它可能不会发生，因为 WASM 既不新鲜也不独特。这个领域已经有了解决方案。

 

我们可以理论上认为，每个人都将拥有一个 WASM 编译器后端，因为它在浏览器中运行，因此对于服务器上的所有内容都有编译器后端可用于 WASM。然而，你自己说过，对于 WASM 来说，Web 并不是最有趣的地方。那么，什么东西将推动 WASM 生态系统变得有趣（使 Web 不再有趣）呢？这是一个棘手的问题。可能行得通，也可能不行。

 

我曾经经历过 Web 上的一个时期，那时每种编程语言都有一个 JavaScript 编译器后端。你可以将 Java 编译成 JavaScript，将 Delphi 编译成 JavaScript，将 C# 编译成 JavaScript 等等。也许其中一些解决方案仍然以某种半废弃的形式存在，但它们大多被放弃了，因为人们意识到编写 JavaScript 的最佳语言就是 JavaScript 本身。这也是 TypeScript 取得如此成功的原因，因为它本质上就是 JavaScript（但带有类型）。

 

对于 WASM，我们可以争论不存在 “在 JavaScript 中编写 JavaScript” 的压力，但它的价值有限，除了 “在 Web 上使用汇编语言” 的极客领域。我知道为什么 Google 需要它。它需要它来索引网络并在网络上放置广告，因此它希望一切都成为网络，这样 Google 就可以索引并在一切上放置广告。这对 Google 有利，但对其他人并非如此。在 Web 上下载并运行像 Photoshop 之类的数百 MB 应用程序的代码绝对是一种糟糕的体验。更不用说应用程序可用的人机交互输入能力和操作系统服务在浏览器中是有限的了。

关于 WebAssembly（WASM）的讨论就如同一场丰富多彩的辩论。就像技术界百家争鸣、百花齐放一样，我们有着各种各样的观点和解决方案。作为多平台运行时环境，WASM 引发了对 Web 开发和跨平台性能的思考。然而，我们必须认识到技术进步是多元的，不同的问题可能需要不同的解决之道。

正如历史上编程语言和工具的竞争一样，我们或许会见证 WASM 在特定领域取得成功，而在其他领域面临挑战。重要的是要从各种观点中吸取智慧，创造更多元化、创新的技术生态系统。无论 WASM 的未来如何，让我们欣然接受这个多彩的时代，继续推动技术的前沿，为未来的 Web 开发和跨平台应用程序创造更好的解决方案。

参考链接：

https://www.theregister.com/2023/09/01/web_assembly_wasm_column

https://news.ycombinator.com/item?id=37385197