WebAssembly能不能取代JavaScript？15张卡通图给你答案！

一切能用Java实现的，终将用Java实现。

一切能编译为WebAssembly的，终将编译为WebAssembly。

前端er们，WebAssembly用上了吗？在浏览器中快速运行非Java语言，比如C、C++、Rust，是不是很香？今天，我们就来用15张小画图说WebAssembly。

有必要先介绍一下小画的创作者。她叫Lin Clark，曾是Mozilla公司的首席研究工程师，精通WebAssembly和Rust。值得一提的是，她的母亲曾为阿波罗登月任务编写汇编语言。如今，Lin是WebAssembly社区响当当的人物，是不是有传承那味儿了？

WebAssembly能做什么？

有了WebAssembly，Java不再是浏览器端的唯一语言。WebAssembly让你能够在网页中快速运行C、C++、Rust等。

再见Java？

WebAssembly并不是要取代Java，二者绝非水火不容。实际上，许多应用程序同时使用WebAssembly和Java。不过，如果硬要对比二者的速度，那么WebAssembly显然是增强型。

Java的性能瓶颈在哪里？

Java的一些根本特性使它速度受限，比如动态类型。直到2008年，JIT（即时编译器）出现，才让Java的性能有了飞跃式提升。

性能提升使得Java开始被用于服务器端。WebAssembly的出现有望使性能曲线再次实现飞跃。

时间都去哪儿了？

JIT出现之前，Java花在各任务上的相对时长是这样的。

有了JIT，Java花在各任务上的相对时长变成了这样。

相比之下，WebAssembly竟然是这样的！

如何让计算机听我发号施令？

想象有机星人来到地球，你被派去和机星人谈判。要怎么交流呢？

你或许需要一位口译官，抑或需要一位笔译官。

口译官可以当场逐字逐句地翻译，这其实就是解释器所做的事情。

笔译官则会将内容写下来，让双方自己理解。这其实就是编译器所做的事情。

解释器刚运行起来时速度较快，但是效率不高，因为同样的代码可能需要重复解释。编译器则恰恰相反。正因为两者各有千秋，所以JIT结合了二者各自的优势。

那么，WebAssembly是如何做到与机星人交流的呢？我们来分析一下机星人的大脑构成。

ALU是算术逻辑单元，相当于机星人大脑负责思考的部分。

register是寄存器，相当于机星人大脑的短时记忆区。

RAM是内存，相当于机星人大脑的长期记忆区。

如果给机星人发送二进制指令，它就会这样解读。

问题是，机星人的大脑构造可能不一样，比如既有可能是x86结构，又有可能是ARM结构。而我们也会使用不同的语言，比如C、C++或者Rust。要两两匹配地进行翻译，工作量实在太大！

为此，人们增加了IR，即中间表示。编译器的前端先将高级语言变成IR，编译器的后端则负责将IR变成汇编码。

那么，WebAssembly的位置在哪里呢？

每一类计算机处理器都有自己的机器码类型。在取得IR代码后，通过一个专门的编译器来运行，这个编译器将IR代码转换为一种专用字节码并放入后缀为.wasm的文件中。

.wasm文件中的字节码还不是机器码，它只是支持WebAssembly的浏览器能够理解的一组虚拟指令。当加载到支持WebAssembly的浏览器中时，浏览器会验证该文件的合法性，然后这些字节码会继续编译为机器码。

如今，各大主流浏览器都已支持WebAssembly。现在就尝试使用WebAssembly吧！