前言
因 前文 抽象语法树 AST 与 编译器 Compiler 整理了部分 抽象语法树 AST 与 编译器 Compiler 相关的内容，进一步地，会有一些问题产生：
- JavaScript 在浏览器是怎么执行的（或者说浏览器是怎么解析的）？
- JavaScript 为什么叫做解释型语言？
- 解析器、解释器、编译器 分别是什么？
- WebAssembly？
因而，找了以下一些文章：
文章
- 来谈谈WebAssembly是个啥？为何说它会影响每一个Web开发者？
- WebAssembly 系列（一）生动形象地介绍 WebAssembly
- JIT —— 来自不同的翻译者
- 汇编 —— 来自不同的翻译者
- WebAssembly 系列（四）WebAssembly 工作原理
- WebAssembly 系列（五）为什么 WebAssembly 更快？
- WebAssembly 系列（六）WebAssembly 的现在与未来
- asm.js 和 Emscripten 入门教程
- WebAssembly 为什么比 asm.js 快？
- 编译了解一下
- 你不知道的浏览器页面渲染机制
对应的，其涉及的概念 / 内容如下：
- WebAssembly
- 编译器
- 解释器
- Just-in-time（JIT）
- 汇编语言 （x86、ARM）
- LLVM
- LLVM IR
- Emscripten
- WebAssembly Explorer
- asm.js
- JS 引擎
- 抽象语法树 AST
以上，基本可覆盖上述 前言 中提出的问题。
发散
闲谈 TypeScript
TypeScript 是在代码开发层面添加了类型等检查，降低了维护成本等，但最终仍然是编译为 JavaScript 执行。
而不是类似 asm.js 一样，让浏览器支持解析/编译。关于 JavaScript 在浏览器上的性能优化，不会有影响。
但其实，因为 V8 / 包括目前的浏览器，已经对 JavaScript 处理得非常好了，TypeScript 用于类型定义 / 开发阶段，作用就已经非常大，也没必要放到浏览器上。
WebAssembly 未来
难道以后的浏览器会
- 要么基于 JavaScript，做更高级的优化？
- 抛弃 JavaScript，使用 WebAssembly 字节码加载方式，更快？
细想下来不会：
- 这里其实有一个问题， dom 操作还是通过 JS，大概也只会用于 react virtual dom diff 以及 加密等 这类在业务中没那么广泛的场景
- 而 慢 最主要还是慢在 dom 操作上，V8 都这么快了，浏览器再快，感觉作用也不大
- 这么看下来，WebAssembly 更多用于其他语言的开发者，可以通过 WebAssembly 提供一些复杂计算之类的功能
