Forrester谈面向开发人员的WebAssembly：从前端到后端

WebAssembly有很多值得喜爱的地方，但开发人员如何决定何时使用它？用什么语言写WebAssembly有关系吗？安全性呢？为了进一步了解前端开发人员需要了解的内容，笔者与Forrester公司专门研究应用程序开发领域的高级分析师Andrew Cornwall展开了讨论。

Cornwall说：“好消息是，功能不会根据你用哪种编码语言编写而改变。用C++、AssemblyScript、Rust编写——这是开发人员的选择。”通常，编译没有垃圾收集器的语言更容易，因此Java、Python和解释语言等语言往往比C或Rust等语言更难在WebAssembly中运行。但最终的结果将是WebAssembly，他指出，人们最好将其视为一种处理器，而不是一种语言。

Cornwall说：“像JavaScript、Java或Python这样的东西，在运行之前需要有一个完整的生态系统。”

他说，通常情况下，开发人员会采用Python的C实现，使用输出WebAssembly的编译器进行编译。现在，他们有了一个用WebAssembly编写的Python解释器，然后可以为其提供常规的Python代码。

“这比将Python转换为WebAssembly本身更容易做到。”他补充道，“一旦它进入WebAssembly，就无关紧要了。它只是运行——本质上与机器代码非常相似。”

他解释说，对于其他受支持的语言，开发人员在编译时选择WebAssembly，而不是在编译器上编译到x86或Arm。编译器输出将运行的字节码——WebAssembly或Wasm是一种可以转换为汇编的低级字节码。字节码是计算机目标代码，解释器将其转换为二进制机器代码，以便计算机的硬件处理器能够读取。从本质上讲，WebAssembly将代码转换为这种可移植的二进制代码格式。因此，它与机器语言的共同点比其他任何东西都多，这就是为什么它如此之快的原因。

前端的Wasm用例

Cornwall表示，当WebAssembly首次问世时，它主要被视为满足前端需求的解决方案。前端的典型用例包括使用大量矩阵数学和视频的操作。他说，如果你需要一些东西立即开始执行，而没有时间等待JavaScript在浏览器中下载和解析，那么WebAssembly是一个很好的解决方案。例如，英国广播公司用Wasm为网站创建了一个视频播放器，Figma是用C++编写的，并编译到WebAssembly，加载时间缩短了三倍。

“WebAssembly可以是流媒体的，所以你可以下载它并立即开始执行。除此之外，WebAssembly在web前端的另一个有趣的用例将不是针对JavaScript开发人员，而是针对其他方面的开发人员。”

他说，这在一定程度上是因为JavaScript通过即时（JIT）编译器运行实际上非常快，并补充说，“如果你让它运行足够长的时间”，开发人员可以使用JavaScript达到一半的原生速度。对其他开发人员来说，Wasm意味着他们可以用自己喜欢的、受支持的代码编写，然后为前端编译到Wasm。

他说：“如果你用另一种语言编写程序，WebAssembly使用的有趣部分基本上就是机器代码。例如，如果有什么东西需要立即非常快速，而你不能等待JIT通过优化来实现它的高速运行，或者如果有什么事情你需要它立即启动，而你不想等待JavaScript被解析的时间，WebAssembly可以帮助你。”

面向后端的Wasm

随着Wasm开始被用于无服务器计算，它开始不再是前端的东西，而是后端的东西。

“与JavaScript虚拟机或容器相比，WebAssembly虚拟机启动得非常快。JavaScript虚拟机以毫秒为单位启动；WebAssembly虚拟机可以以微秒为单位启动。如果你运行的是无服务器功能，这很好，因为你会向服务器发出呼叫，说给我结果。它可以很快启动并给你结果。而其他东西，如JavaScript虚拟机、Java虚拟机和容器需要先开始运行，然后才能用你传递给它们的值做点什么，并给你结果。”

其中包括Kubernetes容器，他补充道。有些地方——无服务器功能或网络浏览器想要请求搜索功能——开发人员希望使用WebAssembly虚拟机而不是Kubernetes容器。

他说：“如果你发送搜索请求，要等到容器出现，运行代码——搜索代码本身，然后将结果发回。通常容器会允许多个连接，因为打开一个容器的成本很高。所以Kubernetes打开容器是有成本的。有了WebAssembly，你就没有那么多成本了。打开容器需要几微秒，而不是几毫秒；或者即使它是一个容器，也可能需要数百毫秒或接近半秒。”

Wasm如何提高安全性

容器也存在安全风险，因为人们倾向于重复使用它们，而不是关闭它们然后重新开始。这对Wasm来说不是问题。

Cornwall说：“你需要担心，在我之前的人是如何影响当前人的请求或当前请求的？有了WebAssembly，它太便宜了，你就把它扔掉了。你只需要写一个无服务器功能，启动VM，执行无服务器功能，然后一直扔下去，等待下一个请求。”

他提醒说，这并不是说Wasm是容器的替代品。在大型数据库上运行大型查询时，容器仍然是需要的，并且是有意义的，在大型数据库中再添加300毫秒的查询并没有多大区别。

他说：“像这样的东西可能会留在容器中，因为管理容器比管理WebAssembly无服务器功能要容易一点，至少现在是这样。当你需要快速调用无服务器功能时，WebAssembly将成为一个补充，而不是接管所有容器。”

Wasm比其他选项更安全的另一种方式是，它只在沙箱中执行——沙箱之外什么都没有。这就是为什么到目前为止，WebAssembly面临的最大安全威胁来自于比特币矿工隐藏在WebAssembly中的网站，导致网站用户无意中被借用CPU进行比特币挖矿。Cornwall解释说，例如，编译到Wasm中的代码不可能访问并发送密码，因为代码留在Wasm沙盒中。

原文链接：

https://thenewstack.io/forrester-on-webassembly-for-developers-frontend-to-backend/