WebAssembly (WASM) 在过去几年一直是一个流行词。 这是一项引起广泛关注但在实践中应用较少的技术。 我一直很好奇它的现状，所以我调查并总结了我的发现。 其中一些可能会让您大吃一惊。
背景
在 WebAssembly 标准问世之前，JAVAscript 是 Web 浏览器唯一支持的编程语言。 然而，WASM 从未被创建为 JavaScript 的替代品，而且它不能因为语言太低级了。 相反，它专门用于补充 Javascript 并解决其在执行计算和内存密集型任务（视频编辑、游戏、CAD 等）时的性能问题。
但是，随着它的发展，还会启用一些有趣且意想不到的副作用场景，正如您将在本文中看到的那样。
在我们继续之前的一些快速说明：
您不直接编写 WASM。 相反，您可以使用 C++ 或 Rust 等高级语言并编译为 WASM。
它以紧凑的二进制格式存储（如机器代码）。
它在安全、隔离的沙箱中执行。
就其本身而言，除了快速处理大量数字外，它并没有做太多事情。 没有网络，没有文件系统，也没有 DOM 访问。
人们使用 WebAssembly 构建的内容可以分为两类：在浏览器中和在服务器中。
在浏览器上
人们在浏览器中使用 WebAssembly 主要出于三个原因：
优化计算和资源密集型任务的性能。
将遗留的本机应用程序迁移到 Web 应用程序。
允许 Javascript 以外的语言在浏览器中运行。
让我们探索这些用例的一些成功的。
Figma
如果您是 UI/UX 设计师或时不时搞砸您的设计的开发人员，那么在过去的一年里您不可能错过 Figma。 这是一款出色的产品，展示了当今网络应用程序可以拥有的最先进性能。
WebAssembly 是 Figma 成功的秘诀之一。 令许多人惊讶的是，虽然是一个网络应用程序，但 Figma 的编辑器是用 C++ 编写的，甚至在 WebAssembly 出现之前。 鉴于浏览器仅执行 Javascript，这怎么可能？ 答案很简单； C++ 代码在交付到 Web 之前被转换为 Javascript。
但为什么不从一开始就使用 Javascript 呢？ 关键的区别在于 C++ 代码是如何转换为 JS 的。 Javascript 是一种非常动态的语言。 为了让它运行得更快，浏览器引擎做了很多魔术来动态优化它。 然而，结果仍然是次优且不可预测的。 有一种方法可以使用 Javascript 获得更好的性能 - 编写代码更像您使用静态语言的方式，以便引擎更容易处理。 Figma 最初使用“asm.js”来实现目标——它本质上是一个以高性能方式将 C++ 代码转换为 Javascript 代码的转译器。
不过归根结底还是Javascript代码，通过网络加载并不紧凑，浏览器还需要解析它的文本。 这就是 WebAssembly 胜过之前方法的地方。 WASM 是一种面向机器的代码。 它比 Javascript 更紧凑，浏览器的处理成本也更低。 通过从 asm.js 迁移到 WebAssebmly，Figma 获得了 3 倍的性能提升。
AutoCAD
作为 1982 年创建的产品，AutoCad 比 Web 还早，而且规模庞大——它有高达 1500 万行的 C++ 代码。 很长一段时间以来，它一直想转移到网络上，但是用 Javascript 重写所有东西是不切实际的：大量的工作和更慢的结果产品。 最后，WebAssembly 作为救世主来了。
在许多方面，AutoCAD 对 WebAssembly 的使用类似于 Figma，只是它有一个额外的问题，即对 windows 操作系统的紧密依赖需要解决。 然而，看到 WebAssembly 作为一项相对较新的技术能够支持如此庞大而复杂的应用程序并使其在现代焕然一新，仍然令人惊叹。
顺便说一下，在 WebAssembly 的帮助下，Adobe Photoshop 也搬到了网络上。
Microsoft Blazor
Blazor 是 Microsoft 通过 WebAssembly 使用其主要后端语言 C# 开发 Web 前端的产品。 正如它的口号所说，目标是在不编写 Javascript 的情况下构建全栈 Web 应用程序，但为什么呢？ 这个想法可能是微软开发人员非常喜欢 C# 并希望在任何地方都使用它。
// A Blazor component@page "/counter"CounterCounter
Current count: @currentCount
Click me// C# below@code {private int currentCount = 0;[Parameter]public int IncrementAmount { get; set; } = 1;private void IncrementCount()currentCount += IncrementAmount;
接触过微软生态的人可能会马上问：这是Silverlight复活了吗？ 不，这不对。 Silverlight 是专有技术，需要安装，并且没有通用的浏览器支持。 相反，Blazor 基于 WebAssembly，它现在是 Web 标准的一部分。
尽管它的价值主张有点奇怪，但 Blazor 很好地展示了 WebAssembly 为浏览器带来更多编程语言的潜力。 我认为任何此类努力都不会威胁到 Javascript 的统治地位，但在某些有趣的小众场景中，这可能非常有用。 例如，直接在浏览器中运行 Python/ target=_blank class=infotextkey>Python，你可以在不运行本地 python 服务器的情况下使用 Jupyter notebook：
服务器端
WebAssembly 的创建者在创建该技术时可能已经想到了在非浏览器环境中运行的可能性，但是服务器端开发人员的热情却大大超出了他们的预期。
这种兴奋是可以理解的——WebAssembly 提供了一种在服务器上执行不受信任代码的理想方式——它具有可移植性、更易于保护、使用的内存比 JVM 或 Docker 少得多，并且是将许多高级语言编译成的自然目标。 对于托管在您的 IDC 中的长时间运行的 Web 服务器进程来说，这可能意义不大，但对于某些场景来说可能是有益的：
需要为其租户大规模运行短期例程的无服务器托管提供商 - 快速启动、低占用空间和沙盒至关重要。
支持运行用户或社区提供的插件的 SaaS 产品
资源非常紧张的边缘环境
WASI 规范的创建开启了服务器端 WASM 的蓬勃发展。 WASI 是 WASM 的同行规范，旨在标准化 WASM 代码如何与其托管环境交互。 在浏览器中，这不是必需的，因为 WASM 是对 Javascript 的增强，它已经可以通过 DOM、BOM 和 Web API 访问其托管环境（浏览器）。 在服务器上时，WASM 是独立的，如果它不能与其环境交互，它就不是很有用。
如果您对现实世界的进展感兴趣，请查看以下将服务器端 WASM 包装到服务中的公司。 随着技术的成熟，它们可能成为传统的基于容器的 PaaS/FaaS 供应商的严峻挑战者。 很长一段时间以来，云业务一直渴望小型、可移植、安全的应用程序运行时。
Cosmonic
Fermyon
What's Next
WebAssembly 仍然是一项年轻的技术。 在浏览器端，用例是可靠的。 然而，它仍然需要发展成为一种更令人愉快的开发方式——今天，你不能像 ES 模块那样直接加载 WASM，需要复杂的 Javascript 胶水代码来连接它。 在服务器端，它更不成熟，它的价值值得商榷。 它等待着主要的行业参与者对其下注并加速其采用。
看看 WebAssembly 将如何在 2023 年进一步突破 Web 开发的界限将会很有趣。
京公网安备 11010802035086号