WebAssembly

WebAssembly 是一种可以使用非 JavaScript 编程语言编写代码并且能在浏览器上运行的技术方案。

WebAssembly 或者 wasm 是一个可移植、体积小、加载快并且兼容 Web 的全新格式

WebAssembly是经过编译器编译之后的代码，体积小、起步快。在语法上完全脱离JavaScript，同时具有沙盒化的执行环境。WebAssembly同样的强制静态类型，是C/C++/Rust的编译目标

用C++实现的求递归的函数。中间是十六进制的Binary Code。右侧是指令文本。其实，中间的十六进制的Binary Code就是WebAssembly。

编译目标
大家可以看到，其可写性和可读性差到无法想象。那是因为WebAssembly不是用来给各位用手一行一行撸的代码，WebAssembly是一个编译目标。
当我们写TypeScript的时候，Webpack最后打包生成的JavaScript文件就是编译目标。可能大家已经猜到了，上图的Binary就是左侧的C++代码经过编译器编译之后的结果。

WebAssembly由来

性能瓶颈
在业务需求越来越复杂的现在，前端的开发逻辑越来越复杂，相应的代码量随之变的越来越多。相应的，整个项目的起步的时间越来越长。在性能不好的电脑上，启动一个前端的项目甚至要花上十多秒。

但是除了逻辑复杂、代码量大，还有另一个原因是JavaScript这门语言本身的缺陷，JavaScript没有静态变量类型。
静态变量类型所带来的问题

这是Microsoft Edge浏览器的JavaScript引擎ChakraCore的结构。我们来看一看我们的JavaScript代码在引擎中会经历什么。

JavaScript文件会被下载下来。
然后进入Parser，Parser会把代码转化成AST（抽象语法树）.
然后根据抽象语法树，Bytecode Compiler字节码编译器会生成引擎能够直接阅读、执行的字节码。
字节码进入翻译器，将字节码一行一行的翻译成效率十分高的Machine Code.
在项目运行的过程中，引擎会对执行次数较多的function记性优化，引擎将其代码编译成Machine Code后打包送到顶部的Just-In-Time(JIT) Compiler，下次再执行这个function，就会直接执行编译好的Machine Code。但是由于JavaScript的动态变量，上一秒可能是Array，下一秒就变成了Object。那么上一次引擎所做的优化，就失去了作用，此时又要再一次进行优化。

什么时候使用WebAssembly？

对性能有很高要求的App/Module/游戏
在Web中使用C/C++/Rust/Go的库

举个简单的例子。如果你要实现的Web版本的Ins或者Facebook， 你想要提高效率。那么就可以把其中对图片进行压缩、解压缩、处理的工具，用C++实现，然后再编译回WebAssembly。

WebAssembly 在很多方面比 JavaScript 更快的原因是：

抓取 WebAssembly 比 JavaScript 花费的时间更少，哪怕当它们都被压缩过。

编码 WebAssembly 比解析 JavaScript 所花费的时间更少。

WebAssembly 比 JavaScript 更加接近机器码而且在服务端就已经经过了优化，所以它编译和优化需要的时间更少。

WebAssembly 不需要重优化，因为它有明确的类型以及内置的额外信息，所以 JS 引擎不需要像优化 JavaScript 那样对它进行推测。

执行阶段花费的时间更少，开发者不必为了写出性能一致性更高的代码而去了解一些编译器的技巧和陷阱。而且 WebAssembly 的一系列的只能对机器来说更加理想。

不需要垃圾回收机制，因为内存都是手动管理的。