在识别和描述核心元素的过程中，我们分享了构建SessionStack时使用的一些经验法则，这是一个轻量级但健壮且高性能的JavaScript应用程序，以帮助用户实时查看和重现其Web应用程序的缺陷。
这次我们来分析WebAssembly的工作原理，以及在如下几个方面和JavaScript进行比较：加载时间，执行速度，垃圾回收，内存使用情况，平台API访问，调试，多线程和可移植性。
WebAssembly的功能WebAssembly（又名wasm）是一种高效的，低级别的编程语言。 它让我们能够使用JavaScript以外的语言（例如C，C ++，Rust或其他）编写程序，然后将其编译成WebAssembly，进而生成一个加载和执行速度非常快的Web应用程序。
加载时间为了加载JavaScript，浏览器必须加载所有.js文本文件。 WebAssembly在浏览器中加载速度更快，因为只有已编译的wasm文件才通过互联网传输。并且wasm是一种非常简洁的二进制格式的低级汇编语言，文件更小。
执行目前Wasm 比本地代码执行速度慢20％。这倒是一个令人吃惊的结果，不过，这是一种编译到沙盒环境中的格式并且在很多约束条件下运行，以确保它没有安全漏洞或者很难攻防这个漏洞。与真实的本地代码相比，其实速度下降很小。但是，未来它会更快。
更好的是，它与浏览器无关 - 所有主要引擎都增加了对WebAssembly的支持，并且现在提供类似的执行时间。我们来看看简单看看V8中发生了什么：
在左边，我们有一些JavaScript源代码，包含JavaScript函数。它首先需要进行分析，以便将所有字符串转换为标记并生成抽象语法树（AST）。AST是JavaScript程序逻辑的内存表示。一旦生成这种表示，V8直接转到机器码。一般来说，只需要遍历树，生成机器代码，便生成了编译好的函数。从这个过程可以看出，这个阶段并没有编译速度的优势。 现在，我们来看看V8管道在下一阶段的功能：
这次我们有TurboFan，V8的优化编译器之一。当您的JavaScript应用程序正在运行时，很多代码在V8中运行。TurboFan可以监控运行缓慢的内容，是否存在瓶颈和热点以优化它们。它将它们推送到后端，这是一个优化的JIT，它可以优化那些非常耗cpu的代码。 虽然它解决了上述问题，但是新的问题在于：分析代码并决定优化哪些内容的过程也会消耗CPU。这反过来又意味着更高的电池消耗，特别是在移动设备上。 然而，wasm不一样在于，它会被插入工作流程中，如下所示：
WebAssembly可信和不可信状态 例如，编译成WebAssembly的C ++程序的内存是连续的内存块，其中没有“漏洞”。有助于提高安全性的wasm的特性之一是执行堆栈与线性内存分离的概念。在一个C ++程序中，你有一个内存堆，你从堆的底部分配，然后从堆顶增涨堆大小。这便产生一个很多恶意软件利用的漏洞：用一个指针就可以在堆栈内存中查找数据从而更改变量，而这些数据本是你不应该访问到的。
WebAssembly采用完全不同的模型。执行堆栈与WebAssembly程序本身是分开的，因此您无法在其中修改并更改变量等内容。而且，这些函数使用整数偏移而不是指针。函数指向一个间接函数表。然后这些直接计算的数字跳转到模块内部的函数中。它是以这种方式构建的，以便您可以同时加载多个wasm模块，形成多个索引列表，并且一切正常。 有关JavaScript中内存模型和管理的更多信息，可以查看关于该主题的非常详细的帖子。
垃圾回收您已经知道JavaScript的内存管理是使用垃圾回收器处理的。
WebAssembly的情况有点不同。它支持手动管理内存的语言。您可以自定义在WASM上的垃圾回收模块，但是这个比较复杂。
目前，WebAssembly是围绕C ++和RUST用例设计的。由于wasm是非常低级的，因此只有汇编语言上一步的编程语言才易于编译。C可以使用普通的malloc，C ++可以使用智能指针，Rust使用完全不同的模式（完全不同的主题）。这些语言不使用GC，因此它们不需要所有复杂的运行时内容来跟踪内存。WebAssembly对他们来说是天作之合。
另外，这些语言并不是100％设计用于调用复杂的JavaScript事物，如DOM。在C ++中编写整个HTML应用程序是没有意义的，因为C ++不是为它设计的。在大多数情况下，当工程师编写C ++或Rust时，他们的目标是WebGL或高度优化的库（例如重数学计算）。
但是，将来WebAssembly将支持不附带GC的语言。
平台API访问