这更多是关于最佳实践的问题。当尝试在 Web 应用程序中应用类似 MVC 的设计模式时，我经常发现自己不知道应该如何更新 View 。
例如，如果我要更新具有 X 个元素的 View_1。是否更好:
A:遍历每个 X 元素，确定哪些元素需要更新并以非常精细的粒度应用 DOM 更改。
或
B:使用模型或其他数据结构提供的数据为整个 View 及其所有封闭元素重新生成标记，并在一次 DOM 操作中替换 View_1 的根元素？
如果我错了，请纠正我。我听说渲染引擎在一次性替换大块 DOM 时通常比多个较小的 DOM 操作更有效。如果是这种情况，则方法 B 更胜一筹。然而，即使使用模板引擎，有时我仍然发现很难避免为未更改的部分 View 重写标记。
在重命名之前，我查看了 Bespin 项目的源代码。我清楚地记得他们实现了某种渲染循环机制，其中 DOM 操作在固定的时间间隔内排队和应用，就像游戏管理帧的方式一样。这类似于方法 A。我也可以看出这种方法背后的基本原理。以这种方式应用的小型 DOM 操作可保持 UI 响应(对于 Web 文本编辑器尤其重要)。同样，通过这种方式，可以通过仅更新需要更改的元素来提高应用程序的效率。静态文本和美学元素可以保持不变。
这些是我对双方的论点。你们有什么感想？我们是在某个地方寻找一种快乐的媒介，还是总的来说一种方法更优越？
此外，是否有任何关于这个特定主题的好书/论文/网站？
(让我们假设有问题的网络应用程序是大量动态更新的交互)
最佳答案
的确，渲染引擎通常处理大块变化比处理多个小变化更快。
tl;dr:bespin 方法是理想的，如果可以的话，在 worker 中进行。
根据更改量的大小，您可能想尝试启动一个工作程序并计算工作程序内部的更改，因为长时间运行的 JS 会锁定 UI。您可以考虑使用以下流程:
- 使用部分 dom 树和父 id 创建一个对象。
- 将对象字符串化为JSON
- 开始一个 worker
- 将字符串化对象传入worker
- 接收并解析字符串。
- 努力更改您传入的 dom 树的所有必要部分。
- 再次将对象字符串化。
- 将对象传回主线程。
- 解析并提取新的 dom 树。
- 再次插入dom。
如果有很多变化和一棵小树，这会更快。如果它是一棵大树并且几乎没有变化，那么只在真实 DOM 树的副本中进行本地更改会更快，然后一次性更新 DOM。
另请阅读有关页面速度的谷歌网站:
https://code.google.com/speed/articles/
尤其是这篇文章:
关于javascript - 多个小型 DOM 操作与一个大型 DOM 操作，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8750101/