Web 技术一直在飞速的发展。WebAssembly 就是 Web 最新发展带来的产物。

WebAssembly 被称为是一种浏览器的字节码技术。有人说 WebAssembly 的发明，相当于再一次发明了 flash、Silverlight，甚至是 java。

本文将主要介绍 WebAssembly 的一些特点，包含什么是 WebAssembly？WebAssembly 的特性？等。

什么是 WebAssembly？

WebAssembly 是除了 JavaScript 以外，另一种可以在浏览器中执行的编程语言。所以当人们说 WebAssembly 更快的时候，一般来讲是与 JavaScript 相比而言的。

Just-in-time 编译器

JavaScript 于 1995 年问世，它的设计初衷并不是为了执行起来快，在前 10 个年头，它的执行速度也确实不快。

紧接着，浏览器市场竞争开始激烈起来。

被人们广为传播的“性能大战”在 2008 年打响。许多浏览器引入了 Just-in-time 编译器，也叫 JIT。基于 JIT 的模式，JavaScript 代码的运行渐渐变快。

正是由于这些 JIT 的引入，使得 JavaScript 的性能达到了一个转折点，JS 代码执行速度快了 10 倍。

随着性能的提升，JavaScript 可以应用到以前根本没有想到过的领域，比如用于后端开发的 Node.js。性能的提升使得 JavaScript 的应用范围得到很大的扩展。

现在通过 WebAssembly，我们很有可能正处于第二个拐点。

随着 WebAssembly 普及，WebAssembly 更快、执行效率更高的特点也会越来越受欢迎。

WebAssembly 解决的问题：

• JavaScript：性能不够理想，以及语言本身的一堆坑
• Flash：私有技术（而且漏洞一堆），并且是纯二进制格式
• Silverlight：私有技术，并且是纯二进制格式
• 各种插件（Plug-in）：安全性问题，平台兼容问题

WebAssembly 的特点

前面我们说了，WebAssembly 更快，效率更高是因为它是二进制格式的。这种二进制格式就是 WebAssembly 的一大特点。

和 WebAssembly 一样，flash 也是二进制格式，但是 flash 漏洞太多，还是私有技术。Flash 在设计的时候也没考虑过操作 DOM 的问题，这样一来搜索引擎和通用的文本分析方案（例如浏览器的搜索功能）对它束手无策。而搜索引擎几乎已经成为 Web 内容提供的中心——它们提供到任何地方的超链接。于是，在 JavaScript 引擎的效率已经相当可观的今天，Flash 不灵了。

flash 的问题并不是二进制的问题。二进制格式有它的好处：相对文本格式更轻量，在互联网上传输的成本更低，解释效率也更高。所以 WebAssembly 最终选择了一个妥协的方案：它要求一个程序段具有两种可互相转换的等价表达：二进制格式和文本格式。这二者可理解为类似机器码和汇编的关系：传输和运行的时候使用二进制格式，展现给人的时候用文本格式。这样就同时保留了二者的优点。当然了，为了安全性，要求以文本格式传输的程序不可被执行。

WebAssembly 的第二个特点就是它不是一项私有技术。

Flash 的诸多漏洞让人们意识到：让一个公司的私有技术主导 Web 并不是什么好主意。新的硬件平台？对不起，不支持。有 bug？等人家更新吧，你什么也干不了。高发热？对不起，你别无选择。没有权限安装浏览器插件？抱歉，你就别用了。不仅仅是 Flash，Silverlight，ActiveX 插件等也是同样的境地。而这些问题对 WebAssembly 来说将不复存在。

第三个特点就是安全性更高了。相比传统的浏览器插件（Plug-in），WebAssembly 的权限设计更好。传统的插件权力太大，它在后台执行了什么，用户根本不知道。而 WebAssembly 再使用某一项权限时都会得到用户的同意才能进行。

WebAssembly 告诉我们，用户应当有权利掌控他们的设备。

WebAssembly 的第四个特点是性能高。WebAssembly 将是一个编译型语言。它的设计目标描述了一个美好的未来：

定义一个可移植，体积紧凑，加载迅捷的二进制格式为编译目标，而此二进制格式文件将可以在各种平台（包括移动设备和物联网设备）上被编译，然后发挥通用的硬件性能以原生应用的速度运行。

总结

如果 WebAssembly 不出现，则 HTML，CSS，JavaScript 必将成为前端界的事实汇编语言：人们不断创造更多的（他们认为更好的）对这三者的高级（high-level）描述形式，并最后以这三者作为“编译目标”。WebAssembly 的出现则提供了一个更好的选择：接近原生的运算效率，开源、兼容性好、平台覆盖广的标准，以及可以借此机会抛弃 JavaScript 的历史遗留问题。