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 年，云原生计算基金会（）生态系统负责人 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 开发的包容性和多样性的重要性。
网友 Phil_kahrl 对 WASM 赞赏有加，尤其在与 JavaScript 相较之下。他盛赞 Rust 与 WASM 的强强联合，以及 Cargo 作为出色的包管理器，使他的项目依赖管理更加得心应手。他还强调了 WASM 捆绑包的潜在大小优势，以及使用 Rust 进行低级操作的便捷性。最重要的是，他认为使用 WASM 编写的应用程序比 React 编写的应用程序更迅捷，尽管这一点也与所使用的框架（Leptos）息息相关。这一观点凸显了 WASM 在前端开发的潜力和吸引力。
网友 jeroenhd 的见解深入透彻，对 WASM 和 JavaScript 的优势与局限进行了剖析，并引发了关于开发工具和开发者教育的重要议题。
网友 jillesvangurp 对 WASM 和前端开发提出了一系列深刻见解，强调了 WASM 作为 Web 开发的重要趋势。他讨论了 WASM 对传统观念的影响以及未来的潜力，展示了对 Web 开发领域不断演变和创新的关注。
网友 jeroenhd 提出的观点强调了 Web 开发领域的一些关键议题，包括调试工具的重要性、新技术的复杂性、性能和用户体验的重要性，以及技术的持续演进对开发者的影响。这些观点促使我们思考如何更好地利用现有工具和技术，并在采用新技术时保持警惕。
网友 3cats-in-a-coat 对 WASM 提出了合理的质疑，担心其在 Web 开发领域可能面临挑战，特别是在性能和用户体验方面。他强调了在采用新技术时需审慎考虑各种因素，并指出 WASM 或许能解决特定问题，但并非所有问题的唯一解决方案。
关于 WebAssembly（WASM）的讨论就如同一场丰富多彩的辩论。就像技术界百家争鸣、百花齐放一样，我们有着各种各样的观点和解决方案。作为多平台运行时环境，WASM 引发了对 Web 开发和跨平台性能的思考。然而，我们必须认识到技术进步是多元的，不同的问题可能需要不同的解决之道。
正如历史上编程语言和工具的竞争一样，我们或许会见证 WASM 在特定领域取得成功，而在其他领域面临挑战。重要的是要从各种观点中吸取智慧，创造更多元化、创新的技术生态系统。无论 WASM 的未来如何，让我们欣然接受这个多彩的时代，继续推动技术的前沿，为未来的 Web 开发和跨平台应用程序创造更好的解决方案。
参考链接：
