虚拟DOM为什么比直接操作DOM快
先说结论：
虚拟dom为什么性能会比直接操作dom快呢？
因为虚拟dom在更新视图的时候会通过diff算法对比更新前后的数据变化，只更新产生变化的dom。
现在来对比一下原生和虚拟dom两种方式的区别
采用原生innerHTML属性创建页面
通过innerHtml创建页面，需要写html字符串。将html字符串赋值给innerHTML属性。在渲染页面过程中，需要先把字符串解析成dom树，这属于dom层面的计算，其性能远比JavaScript的计算差。
const html = '<div>.......</div>'div.innerHtml = html
innerHTML创建页面的性能消耗：HTML字符拼接的计算量 + innerHTML的DOM计算量。
采用虚拟DOM方式创建页面
通过虚拟DOM方式创建页面
第一步需要创建JavaScript对象，这个对象用来描述真实DOM
第二步需要将虚拟DOM树递归遍历并创建真实DOM。
通过虚拟DOM方式创建页面的性能消耗：创建JavaScript对象的计算量 + 创建真实DOM的计算量。
对比JavaScript层面与DOM层面计算两个差距不大。
innerHTML与虚拟DOM方式更新页面对比
通过innerHTML属性更新页面时，即使只更改了一个字母，也需要重新设置inner HTML的值。这意味着，需要销毁所有DOM元素再重新渲染html字符串的所有内容。
而通过虚拟DOM方式更新页面时，需要重新创建JavaScript对象（虚拟DOM），再通过diff算法比较更新前后的差异。只更新产生变化的DOM元素。
虽然更新页面时虚拟DOM方式需要增加diff算法的性能消耗，但是这也属于JavaScript层面的计算，因此不会产生数量级上的差异。而innerHTML则需要全部更新。
无论页面多复杂，虚拟DOM都只会更新需要更新的部分，而对innerHTML来说，页面越复杂消耗的性能越大。
因此，虚拟DOM、innerHTML和原生JavaScript更新DOM元素的性能消耗比较如下。
原生DOM消耗的性能最少，但是需要手动创建、删除、修改大量DOM元素。可维护性也很差。
innerHTML通过拼接HTML方式修改dom元素，其可维护性较高，但是事件绑定仍然需要原生JavaScript处理。在模板很大并且更新很少时，这种方式消耗性能最多。
虚拟DOM方式采用声明式写法，维护起来最方便，性能虽然比不上原生JavaScript方式，但是在可维护性和心智负担小的前提下比innerHTML方式要强很多。