WebAssembly（WASM）在过去几年中一直是流行语。这是一项引起大量关注但在实践中使用较少的技术。我对它的当前状态感到好奇，因此我调查并总结了我的发现。其中一些可能会让您感到惊讶。
背景
JavaScript是唯一由Web浏览器支持的编程语言，直到WebAssembly标准出现为止。但是，WASM从未被创建为JavaScript的替代品，并且不能因为语言如此低级。相反，它是专门用于补充JavaScript并在执行计算和记忆密集型任务时解决其性能问题 - 视频编辑，游戏，CAD等。
但是，随着它的发展，您还可以在本文中看到一些有趣且意外的副作用方案。
我们继续前进之前：
- 您不直接写WASM。相反，您使用C ++或Rust等高级语言并将其编译为WASM。
- 它以紧凑的二进制格式（如机器代码）存储。
- 它在安全的，孤立的沙箱中执行。
- 本身，除了快速处理大批数字之外，它没有多大作用。没有网络，没有文件系统，也没有DOM访问。
人们正在使用WebAssembly构建的内容可以分为两类：在浏览器和服务器中。
在浏览器中
人们在浏览器中使用WebAssembly主要是出于三个原因：
- 优化计算和资源密集型任务的性能。
- 将传统本机应用程序迁移到Web应用程序。
- 允许JavaScript以外的其他语言在浏览器中运行。
让我们在这些用例中探索一些巨大的成功。
无花果
如果您是UI/UX设计师或不时弄乱设计的开发人员，那么在过去的一年中，您不会错过Figma。这是一个很棒的产品，展示了网络应用程序今天可以拥有的最新性能。
WebAssembly是Figma成功的秘诀之一。令人惊讶的是，尽管Web Assembly黎明之前，Figma的编辑器都是用C ++编写的。给定浏览器仅执行JavaScript，该怎么可能？答案很简单； C ++代码在传递到网络之前已转移到JavaScript中。
但是为什么不从一开始就没有JavaScript呢？至关重要的差异是如何将C ++代码转移到JS。 JavaScript是一种非常动态的语言。为了使其快速运行，浏览器发动机会做很多魔术来即时进行优化。但是，结果仍然是最佳和不可预测的。有一种方法可以通过JavaScript获得更好的性能 - 更像您使用静态语言的方式更加像使用静态语言，以使引擎更容易处理。 Figma最初使用“ ASM.JS”来实现目标 - 它本质上是一种以表演方式将C ++代码转换为JavaScript代码的转板器。
最终，它仍然是JavaScript代码，通过网络加载并不紧凑，并且浏览器仍然需要解析其文本。这是WebAssembly击败先前方法的地方。 WASM是一个面向机器的代码。它比JavaScript要紧凑得多，并且浏览器处理的成本要低得多。通过从asm.js迁移到Webassebmly，Figma got a 3x performance gain。
AutoCAD
作为1982年创建的产品，AutoCAD比Web年龄较大，并且大小可怕 - 它的C ++代码高达1500m。它一直想移到网络相当长的一段时间，但是用JavaScript重写所有内容只是不切实际的：很多工作和结果较慢的结果。最后，WebAssembly作为救世主。
在许多方面，AutoCAD对WebAssembly的使用类似于无花果，除了它具有严格依赖Windows OS的额外问题。但是，看到WebAssembly作为一项相对较新的技术仍然是可行的，可以支持如此大型而复杂的应用程序，并在现代时代焕然一新。
顺便说一句，Adobe Photoshop also moved to the web在WebAssembly的帮助下。
Microsoft Blazor
Blazor是Microsoft通过WebAssembly开发其主要后端语言C＃的Web前端的产品。正如其口号所说，目标是在不编写JavaScript的情况下构建全堆栈网络应用程序，但是为什么呢？这个想法可能是Microsoft开发人员非常喜欢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，它现在是Web标准的一部分。
尽管其价值主张有些怪异，但《大火》是WebAssembly为浏览器带来更多编程语言的潜力的绝佳演示。我认为任何这样的努力都不会威胁到JavaScript的统治，但是可能会有有趣的利基场景在其中非常有用。例如，当Python直接在浏览器中运行时，您可以在不运行本地Python服务器的情况下使用Jupyter笔记本：
在服务器上
WebAssembly的创建者可能会考虑到创建技术时在非浏览器环境中运行的可能性，但是服务器端开发人员的热情远远超出了他们的期望。
兴奋是可以理解的 - WebAssembly提供了一种理想的方式来执行服务器上的不信任代码 - 它是可移植的，更易于安全的，比JVM或Docker使用的内存要少得多，并且是自然的目标，可以将许多高级语言编译到许多高级语言中。对于IDC中托管的长期运行的Web服务器流程可能并不多，但是对某些情况可能是有益的：
- 无服务的托管提供商，他们需要在广泛的规模上为租户运行短暂的例行程序 - 快速启动，占地面积和沙箱至关重要。
- 支持运行用户或社区提供的插件的SaaS产品
- 资源非常紧密的边缘环境
创建WASI规范开始了服务器端WASM的绽放。 WASI是WASM的同行规范，旨在标准化WASM代码如何与托管环境相互作用。在浏览器中，这不是必需的，因为WASM是JavaScript的增强，它已经可以通过DOM，BOM和Web API访问其托管环境（浏览器）。当在服务器上，WASM是独立的，如果无法与环境交互，则不是很有用。
如果您对现实世界的进度感兴趣，请查看以下服务器端WASM进入服务的公司。随着技术的成熟，它们可能会成为传统基于容器的PAAS/FAAS供应商的严重挑战者。云业务渴望在相当长的一段时间内使用小型，便携式，安全的应用程序运行时。
宇宙
费米
Cloudflare Wasi支持
Announcing support for WASI on Cloudflare Workers
今天，我们宣布对Cloudflare工人的WASI（WebAssembly系统接口）的实验支持，并在Wrangler2中提供支持，以使与之合作的乐趣
blog.cloudflare.com
下一步是什么
WebAssembly仍然是一项年轻技术。在浏览器侧，用例是固体的。但是，它仍然需要发展成一个更令人愉悦的事情要开发 - 今天，您不能像ES模块那样直接加载WASM，并且复杂的JavaScript胶水代码是连接它所必需的。在服务器端，它更不成熟，其值值得商bat。它正在等待主要行业参与者下注并加速其采用。
看到如何进一步的WebAssembly在2023年推动Web开发边界。
P.S。我们正在构建ZenStack - 一种工具包，用于使用Next.js + Typescript构建安全的CRUD应用程序。我们的目标是让您节省时间编写样板代码，并专注于构建重要的内容。