一切能用JavaScript实现的，终将用JavaScript实现。
一切能编译为WebAssembly的，终将编译为WebAssembly。
前端er们，WebAssembly用上了吗？在浏览器中快速运行非JavaScript语言，比如C、C++、Rust，是不是很香？今天，我们就来用15张小画图说WebAssembly。
有必要先介绍一下小画的创作者。她叫Lin Clark，曾是Mozilla公司的首席研究工程师，精通WebAssembly和Rust。值得一提的是，她的母亲曾为阿波罗登月任务编写汇编语言。如今，Lin是WebAssembly社区响当当的人物，是不是有传承那味儿了？
WebAssembly能做什么？
有了WebAssembly，JavaScript不再是浏览器端的唯一语言。WebAssembly让你能够在网页中快速运行C、C++、Rust等。
再见JavaScript？
WebAssembly并不是要取代JavaScript，二者绝非水火不容。实际上，许多应用程序同时使用WebAssembly和JavaScript。不过，如果硬要对比二者的速度，那么WebAssembly显然是增强型。
JavaScript的性能瓶颈在哪里？
JavaScript的一些根本特性使它速度受限，比如动态类型。直到2008年，JIT（即时编译器）出现，才让JavaScript的性能有了飞跃式提升。
性能提升使得JavaScript开始被用于服务器端。WebAssembly的出现有望使性能曲线再次实现飞跃。
时间都去哪儿了？
JIT出现之前，JavaScript花在各任务上的相对时长是这样的。
有了JIT，JavaScript花在各任务上的相对时长变成了这样。
相比之下，WebAssembly竟然是这样的！
如何让计算机听我发号施令？
想象有机星人来到地球，你被派去和机星人谈判。要怎么交流呢？
你或许需要一位口译官，抑或需要一位笔译官。
口译官可以当场逐字逐句地翻译，这其实就是解释器所做的事情。
笔译官则会将内容写下来，让双方自己理解。这其实就是编译器所做的事情。
解释器刚运行起来时速度较快，但是效率不高，因为同样的代码可能需要重复解释。编译器则恰恰相反。正因为两者各有千秋，所以JIT结合了二者各自的优势。
那么，WebAssembly是如何做到与机星人交流的呢？我们来分析一下机星人的大脑构成。
- ALU是算术逻辑单元，相当于机星人大脑负责思考的部分。
- register是寄存器，相当于机星人大脑的短时记忆区。
- RAM是内存，相当于机星人大脑的长期记忆区。
如果给机星人发送二进制指令，它就会这样解读。
问题是，机星人的大脑构造可能不一样，比如既有可能是x86结构，又有可能是ARM结构。而我们也会使用不同的语言，比如C、C++或者Rust。要两两匹配地进行翻译，工作量实在太大！
为此，人们增加了IR，即中间表示。编译器的前端先将高级语言变成IR，编译器的后端则负责将IR变成汇编码。
那么，WebAssembly的位置在哪里呢？
每一类计算机处理器都有自己的机器码类型。在取得IR代码后，通过一个专门的编译器来运行，这个编译器将IR代码转换为一种专用字节码并放入后缀为.wasm的文件中。
.wasm文件中的字节码还不是机器码，它只是支持WebAssembly的浏览器能够理解的一组虚拟指令。当加载到支持WebAssembly的浏览器中时，浏览器会验证该文件的合法性，然后这些字节码会继续编译为机器码。
如今，各大主流浏览器都已支持WebAssembly。现在就尝试使用WebAssembly吧！
本文中的插图由Lin Clark创作，源网址如下：
https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/
本文对插图的使用经Lin Clark同意，且遵守CC BY-SA 3.0协议。
https://creativecommons.org/licenses/by-sa/3.0/
