WebAssembly 被誉为第 4 种 web 语言
这几年，总听人频频提起 WebAssembly，说实话，还挺感兴趣的。
在大多数前端人的印象中，它可能都是“新技术、很抽象”又或是“不太了解、没用过”。
如果让非要严谨的来定义的话，就是：“ WebAssembly 是基于栈式虚拟机的虚拟二进制指令集（V-ISA），它被设计为高级编程语言的可移植编译目标”。
这么说就很难理解了，那么换个说法。早在 2019 年 12 月，W3C 就正式宣布，WebAssembly 将成为除现有的 HTML、CSS 以及 JavaScript 之外的第四种，官方推荐在 Web 平台上使用的“语言”。
自然而然的，就有不少人在关注：WebAssembly 会取代 JavaScript 吗？他们之间是什么关系？
其实就目前 MVP 标准所提供的特性和能力来看，WebAssembly 与 JavaScript 之间还只能够是协作与补充的关系。WebAssembly 可以在某些场景中弥补 JavaScript 性能不足的短板。而想要在 Web 浏览器中使用 WebAssembly，我们也离不开相关 JavaScript API 提供的帮助。JavaScript 作为“老大哥”，在维持“两者关系”的过程中，仍然有着举足轻重的作用。
但随着 Post-MVP 标准的发展，这种关系可能会变得愈加脆弱，尤其当 WebAssembly ES Module 与 Type Interface 等提案被标准化并由浏览器实现后，WebAssembly 便会从依存走向独立。
举个实际应用中的例子，选择两款市面上最为常见的浏览器，分别测量我们构建的这个 DSP Web 应用在 JavaScript 滤镜和 WebAssembly 滤镜两个选项下的视频播放帧率。
- Chrome Version 84.0.4147.89 (Official Build) (64-bit)
- Firefox Version 79.0
实际测试结果的截图如下所示。其中左侧为 JavaScript 版本滤镜函数，右侧为对应的 WebAssembly 版本滤镜函数。
首先是 Chrome：
然后是 Firefox：
可以看到，同样实现逻辑的滤镜函数，在对应 JavaScript 版本和 WebAssembly 版本下有着极大的性能差异。WebAssembly 版本函数的帧画面实时处理速率几乎是对应 JavaScript 版本函数的一倍之多。当然，上述的性能对比结果仅供参考，应用的实际表现是一个综合性的结果，与浏览器版本、代码实现细节、编译器版本甚至操作系统版本都有着密切的关系。
这只是 WebAssembly 应用的冰山一角，实际上，Web 前端正变得越来越开放。如今，我们不仅能够直接使用 HTML、JavaScript 来编写各类跨端应用程序，WebAssembly 的出现更能够让我们直接在 Web 平台上使用那些业界已存在许久的众多优秀 C/C++ 代码库。
除此之外，WebAssembly 还能让 Web 应用具有更高的性能，甚至让 Web 应用能够与原生应用展开竞争，不仅如此，走出 Web，WASI 的出现更是为 WebAssembly 提供了更大的舞台。可以说，在未来的 3～5 年里，WebAssembly 会被逐渐广泛地应用到包括 Web 在内的各个平台和业务领域中。
发表评论 (审核通过后显示评论)：