「转」VirtualDOM 真的比操作原生 DOM 快吗？ · 看不见我的美 · 是你瞎了眼
原生 DOM 操作 vs 通过框架封装操作
这是一个性能 vs 可维护性的取舍。
框架的意义在于为你掩盖底层的 DOM 操作，让你用更声明式的方式来描述你的目的，从而让你的代码更容易维护。
没有任何框架可以比纯手动的优化 DOM 操作更快，因为框架的 DOM 操作层需要应对任何上层 API 可能产生的操作，它的实现必须是普适的。
针对任何一个 BenchMark，我都可以写出比任何框架更快的手动优化，但是那有什么意义呢？在构建一个实际应用的时候，你难道为每一个地方都去做手动优化吗？出于可维护性的考虑，这显然不可能。
框架给你的保证是，你在不需要手动优化的情况下，我依然可以给你提供过得去的性能。
对 React 的 VirtualDOM 的误解
React 从来没有说过“React 比原生操作 DOM 快”。
React 的基本思维模式是每次有变动就整个重新渲染整个应用。如果没有 VirtualDOM，简单来想就是直接重置 innerHTML。
很多人都没有意识到，在一个大型列表所有数据都变了的情况下，重置 innerHTML 其实是一个还算合理的操作。
真正的问题是在“全部重新渲染”的思维模式下，即使只有一行数据变了，它也需要重置整个 innerHTML，这时候显然就有大量的浪费。
我们可以比较一下 innerHTML 和 VirtualDOM 的重绘性能消耗：
- innerHTML: render html string + O(template size) + 重新创建所有 DOM 元素 O(DOM size)；
- VirtualDOM: render VirtualDOM + diff O(template size) + 必要的 DOM 更新 O(DOM change)。
VirtualDOM 的 render + diff 显然比渲染 html 字符串要慢，但是！它依然是纯 JS 层面的计算，比起后面的 DOM 操作来说，依然便宜了太多。
可以看到，innerHTML 的总计算量不管是 JS 计算还是 DOM 操作都是和整个界面的大小相关，但 VirtualDOM 的计算量里面，只有 JS 计算和界面大小相关，DOM 操作是和数据的变动量相关的。
前面说了，和 DOM 操作比起来，JS 计算是极其便宜的。这才是为什么要有 VirtualDOM：
- 不管你的数据变化多少，每次重绘的性能都可以接受；
- 你依然可以用类似 innerHTML 的思路去写你的应用。
MVVM vs VirtualDOM
相比起 React，其他 MVVM 系框架比如 Angular、Knockout 以及 Vue、Avalon 采用的都是数据绑定：通过 Directive/Binding 对象，观察数据变化并保留对实际 DOM 元素的引用，当有数据变化时进行对应的操作。
MVVM 的变化检查是数据层面的，而 React 的检查是 DOM 结构层面的。
MVVM 的性能也根据变动检测的实现原理有所不同：
- Angular 的脏检查使得任何变动都有固定的 O(watcher count) 的代价；
- Knockout/Vue/Avalon 都采用了依赖收集，在 JS 和 DOM 层面都是 O(change)；
- 脏检查：scope digest O(watcher count) + 必要 DOM 更新 O(DOM change)；
- 依赖收集：重新收集依赖 O(data change) + 必要 DOM 更新 O(DOM change)。
可以看到，Angular 最不效率的地方在于任何小变动都有的和 watcher 数量相关的性能代价。但是！当所有数据都变了的时候，Angular 其实并不吃亏。依赖收集在初始化和数据变化的时候都需要重新收集依赖，这个代价在小量更新的时候几乎可以忽略，但在数据量庞大的时候也会产生一定的消耗。
MVVM 渲染列表的时候，由于每一行都有自己的数据作用域，所以通常都是每一行有一个对应的 ViewModel 实例，或者是一个稍微轻量一些的利用原型继承的"scope"对象，但也有一定的代价。所以，MVVM 列表渲染的初始化几乎一定比 React 慢，因为创建 ViewModel/scope 实例比起 VirtualDOM 来说要昂贵很多。
这里所有 MVVM 实现的一个共同问题就是在列表渲染的数据源变动时，尤其是当数据是全新的对象时，如何有效地复用已经创建的 ViewModel 实例和 DOM 元素。
假如没有任何复用方面的优化，由于数据是“全新”的，MVVM 实际上需要销毁之前的所有实例，重新创建所有实例，最后再进行一次渲染！这就是为什么题目里链接的 Angular/Knockout 实现都相对比较慢。相比之下，React 的变动检查由于是 DOM 结构层面的，即使是全新的数据，只要最后渲染结果没变，那么就不需要做无用功。
Angular 和 Vue 都提供了列表重绘的优化机制，也就是“提示”框架如何有效地复用实例和 DOM 元素。比如数据库里的同一个对象，在两次前端 API 调用里面会成为不同的对象，但是它们依然有一样的 uid。这时候你就可以提示 track by uid 来让 Angular 知道，这两个对象其实是同一份数据。那么原来这份数据对应的实例和 DOM 元素都可以复用，只需要更新变动了的部分。或者，你也可以直接 track by $index 来进行“原地复用”：直接根据在数组里的位置进行复用。
在题目给出的例子里，如果 Angular 实现加上 track by $index 的话，后续重绘是不会比 React 慢多少的。甚至在 dbmonster 测试中，Angular 和 Vue 用了 track by $index 以后都比 React 快，顺道说一句，React 渲染列表的时候也需要提供 key 这个特殊 prop，本质上和 track-by 是一回事。