react.js 以高效的 ui 渲染著称，其中一个很重要的原因是它维护了一个虚拟 dom，用户可以直接在虚拟 dom 上进行操作，react.js 用 diff 算法得出需要对浏览器 dom 进行的最小操作，这样就避免了手动大量修改 dom 的时候造成的性能损失。等等，明明是在中间加了一层，为什么结果反而变快了呢？react.js 的核心思想是认为 dom 操作是缓慢的，因此可以需要最小化 dom 操作，以换取整体的性能提升。dom 操作慢是有目共睹的，而其他 javascript 脚本的运行速度就一定快吗？
在 v8 出世之前，这个问题的答案是否定的。google 早年商业模式建立在 web 的基础上，当它在浏览器中写出 gmail 这样一个无比复杂的 web app 的时候，它不可能意识不到浏览器难以忍受的性能，而这主要是因为 javascript 的执行速度太慢。2008 年 9 月，google 决定自己造一个 javascript 引擎来改变这一现状—— v8。当搭载着 v8 的 chrome 浏览器出现在市场上的时候，它的速度远远甩开了当时的所有浏览器。浏览器性能的空前提升让复杂的 web app 成为了可能。
近七年过去，浏览器的性能随着 cpu 的性能不断上升，但再也没有获得过 2008 年那样突破性的增长。v8 到底用了什么样的技术让 javascript 的性能获得了如此大的提升呢？
　v8 的优化
要说如何让 javascript 变快，就应该先来谈谈它为什么会慢。众所周知 javascript 是 brendan eich 这个家伙用了一周多的时间开发出来的，相比现如今如日中天的 swift 是 apple 的一个团队四年工作的成果，你首先可能就不应该对它有过高的期待。事实上，brendan eich 并未意识到自己要开发的是这样一个体量的语言。为了程序员编写时的灵活，他将 javascript 设计成为弱类型的语言，并且在运行时可以对对象的属性增添删改。难倒一大群人的 c++ 中的继承、多态，还有什么模板、虚函数、动态绑定这些概念在 javascript 中完全不存在了。那这些工作谁来做了呢？自然就只有 javascript 引擎。由于不知道变量类型，它在运行时做着大量的类型推导工作。在 parser 完成工作建出一棵抽象语法树（ast）的时候，引擎会把这棵 ast 翻译成字节码（bytecode）交给字节码解释器去执行。其中最拖慢性能的一步就是解释器执行字节码的阶段。回望当时，大家不知道解释器性能低下吗？其实不是，这样设计的原因是当时的人们普遍认为 javascript 作为一种给设计师开发的语言（前端工程师有没有心里一凉？），并不需要太高的性能，这样做符合成本，也满足需求。
v8 做的工作主要就是去掉了这个拖慢引擎速度的部分，它从 ast 直接生成了 cpu 可执行的机器码。这种即时编译的技术被称为 jit （just in time）。如果你足够好奇，一个自然的想法就是，这到底是怎么办到的？
我们举一个例子来说：
function foo(x, y) { this.x = x; this.y = y; } var foo = new foo(7, 8); var bar = new foo(8, 7); foo.z = 9;
属性读取
首先是数据结构。你打算如何索引对象的属性？我们已经太熟悉 json 中 key: value 的数据结构，但在内存中可以以 key 来索引吗？value 在内存中的位置可以确定吗？当然可以，只要对每个对象维护一个表，里面存着每个 key 对应的 value 在内存中的位置就可以了不是吗？
这里的陷阱在于，你需要对每一个对象都维护这样一个表。为什么？我们来看看 c 语言是怎么做的。
struct foo { int x, y; }; struct foo foo, bar; foo.x = 7; foo.y = 8; bar.x = 8; bar.y = 7; // cant' set foo.z
仔细想想大学时候的教材，foo.x 和 foo.y 的地址是可以直接算出来的呀。这是因为成员 x 和 y 的类型是确定的，javascript 里完全可以 foo.x = "hello" ，而 c 语言就没办法这样做了。
v8 不想给每个对象都维护一个这样的表。它也想让 javascript 拥有 c/c++ 直接用偏移就读出属性的特性。所以它的解决思路就是让动态类型静态化。v8 实现了一个叫做隐藏类（hidden class）的特性，即给每个对象分配一个隐藏类。对于 foo 对象，它生成一个类似于这样的类：
class foo { int x, y; }
当新建一个 bar 对象的时候，它的 x 和 y 属性恰好都是 int 类型，那么它和 foo 对象就共享了这个隐藏类。把类型确定以后，读取属性就只是在内存中增加一个偏移的事情了。而当 foo 新建了 z 属性的时候，v8 发现原来的类不能用了，于是就会给 foo 新建一个隐藏类。修改属性类型也是类似。
inline caching
由上可知，当访问一个对象的属性的时候，v8 首先要做的就是确定对象当前的隐藏类。但每次这样做的开销也很大，那很容易想到的另一个计算机中常用的解决方案，就是缓存。在第一次访问给定对象属性的时候，v8 将假设所有同一部分代码的其他对象也都使用了这个对象的隐藏类，于是会告诉其他对象直接使用这个类的信息。在访问其他对象的时候，如果校验正确，那么只需要一条指令就可以得到所需的属性，如果失败，v8 就会自动取消刚才的优化。上面这段话用代码来表述就是：
foo.x
# ebx = the foo object cmp [ebx,<hidden class offset>],<cached hidden class> jne <inline cache miss> mov eax,[ebx, <cached x offset>]
这极大提升了 v8 引擎的速度。
　随着 intel 宣布 tick-tock 模型的延缓，cpu 处理速度不再能像之前一样稳步增长了，那么浏览器还能继续变快吗？v8 的优化是浏览器性能的终点吗？
javascript 的问题在于错误地假设前端工程师都是水平不高的编程人员（如果不是，你应该不会读到这里），岂图让程序员写得舒服而让计算机执行得痛苦。在现代浏览器引擎已经优化到这个地步的时候，我们不禁想问：为什么一定是 javascript ？前端工程师是不是可以让出一步，让自己多做一点点事情，而让引擎得以更高效地优化性能？javascript 成为事实上的浏览器脚本标准有历史原因，但这不能是我们停止进步的借口。
当 web assembly 正式宣布的时候，我才确定了不仅仅是我一个名不见经传的小程序员有这样的想法，那些世界上最顶级的头脑已经开始行动了。浏览器在大量需求的驱动下正在朝着一个高性能的方向前进，浏览器究竟可以有多快，2015 可能是这条路上另一个转折点。