多个小 DOM 操作 vs 一个大 DOM 操作

Question

这更多的是关于最佳实践的问题。当尝试在 Web 应用程序中应用类似 MVC 的设计模式时，我经常发现自己想知道应该如何更新视图。

例如，如果我要更新具有 X 个元素的 View_1。是不是更好：

答：迭代每个 X 元素，找出哪些元素需要更新，并以非常细的粒度应用 DOM 更改。

或者

B：使用 Model 或其他数据结构提供的数据来重新生成整个 View 及其所有封闭元素的标记，并在一次 DOM 操作中替换 View_1 的根元素？

如果我错了请纠正我。我听说渲染引擎在一次性替换大块 DOM 方面通常比多个较小的 DOM 操作更有效。如果是这种情况，那么方法 B 更优越。然而，即使使用模板引擎，我有时仍然发现很难避免重写未更改的视图部分的标记。

在重命名 Bespin 项目之前，我查看了它的源代码。我清楚地记得他们实现了某种渲染循环机制，其中 DOM 操作按固定时间间隔排队并应用，就像游戏管理帧的方式一样。这与方法 A 类似。我也可以看到这种方法背后的基本原理。以这种方式应用的小型 DOM 操作可以保持 UI 的响应能力（对于 Web 文本编辑器尤其重要）。同样，通过这种方式，只需更新需要更改的元素即可使应用程序更加高效。静态文本和美学元素可以保持不变。

这些是我对双方的论点。你们有什么感想？我们是否在某个地方寻找一种折中方案，或者一种方法总体上更优越？

另外，有关于这个特定主题的好书/论文/网站吗？

（假设所涉及的 Web 应用程序与许多动态更新交互频繁）

Answer 1

在使用各种 Web 技术 3 年之后，我想我终于在两种方法之间找到了一个很好的平衡：虚拟 DOM

像 vdom、Elm、mithril.js 和 Facebook React 这样的库在某种程度上跟踪实际 DOM 的薄抽象，找出需要更改的内容，并尝试应用尽可能小的 DOM 更改。

例如

https://github.com/Matt-Esch/virtual-dom/tree/master/vdom