是否需要 Virtual-DOM？一个简化的示例

在开始之前，让我们看看浏览器 DOM 是否比在 JavaScript 引擎上执行的所有 JavaScript 代码慢。

与其使用大量的虚拟 DOM 代码，不如我们来看一段非常简短的 JavaScript 代码片段，其中使用一个数组在一个循环中收集递增的数字。循环结束后，它将该数字数组添加到 DOM 中。

在第二种情况下，让我们在每次循环递增时更新循环内的 DOM。

这是 jsperf 的截图，其中编写了一个用于比较的小型测试用例。结果如下所示：

结果清楚地表明，每次递增都更新 DOM比执行 javascript 代码片段并仅更新一次 DOM慢 100% 。

我们来看看为什么速度慢了100%？

回顾基础知识，JavaScript 引擎会先执行所有代码，然后 DOM 和 CSSOM 才能准备就绪。只有在此之后，屏幕上的第一个像素才会被绘制出来。

DOM 之于浏览器引擎，JavaScript 之于 JavaScript 引擎。每当 DOM 更新时，这两个引擎都需要通信，这就导致了延迟。

由于在首次绘制之前会执行一些工作流程，每次通过 JavaScript 代码更新 DOM 时domElement.innerHTML = "someValue"，CSSOM 也需要完成。这会进一步增加延迟。然后，下一行 JavaScript 代码又会被执行。除非使用 defer 或 async 标签，否则这需要在 JavaScript 引擎和浏览器引擎之间切换执行。

虚拟 DOM 的帮助

虚拟 DOM 拥有一个由 JavaScript 引擎自身存储和执行的树状结构，这使得运行速度大大提升。

• 两台发动机通信的次数减少。
• 由于样式不需要在虚拟 DOM 中应用，因此无需完成 CSSOM。
• 每次虚拟 DOM 更新时，都不会发生执行切换，因为它仅由 Javascript 引擎运行。
• 虽然在不需要的时候不更新虚拟 DOM 是一种好做法，但这样做会造成相当大的性能损失，从而影响应用程序的性能。
• 这意味着流畅的用户交互、更快的首次渲染时间，从而带来更好的搜索引擎排名。
• 我们甚至还没讨论如何高效地编写虚拟 DOM。然而，即使只考虑少数几种情况，它也是有益的。

就目前来看，虚拟 DOM 的优势显而易见。除非浏览器能找到解决 DOM 更新延迟问题的策略，否则这种情况将持续下去。

如果您能对以上文章提出一些评论，将对我进一步提升写作水平大有裨益。谢谢！