这是一个关于最佳实践的问题。当尝试在Web应用程序中应用类似MVC的设计模式时，我经常发现自己想知道如何更新视图。
例如，如果我要更新具有X个元素的View_1。是否更好：
A：遍历每个X元素，找出哪些需要更新，并以非常精细的粒度应用DOM更改。
或
B：使用Model或其他数据结构提供的数据为整个View及其所有封闭元素重新生成标记，并在一个DOM操作中替换View_1的根元素？
如果我弄错了，请纠正我。我听说渲染引擎通常比多个较小的DOM操作更有效地一次性替换大块DOM。如果是这种情况，则方法B优越。但是，即使使用模板引擎，我仍然有时会发现很难避免对未更改的部分视图重写标记。
在重命名项目之前，我查看了项目Bespin的源代码。我清楚地记得他们实现了某种渲染循环机制，其中DOM操作排队并以固定的时间间隔应用，就像游戏管理他们的帧一样。这与方法A类似。我也可以看到这种方法背后的基本原理。以这种方式应用的小DOM操作使UI响应（对于Web文本编辑器尤其重要）。同样，通过仅更新需要更改的元素，可以使应用程序更有效。静态文本和美学元素可以保持不变。
这是我对双方的论点。你们有什么感想？我们是在某个地方寻找一种快乐的媒介，还是一种方法基本上是优越的？
此外，是否有关于此特定主题的好书/论文/网站？
（假设有问题的网络应用程序与很多动态更新交互很重要）
答案 0 :(得分：2)
渲染引擎通常比多次小变化更快地处理大块变化。
tl; dr：bespin方式是理想的，如果可以的话，可以在工作人员中进行。
根据您可能想要尝试启动工作程序的更改量的大小，并且自从长时间运行JS锁定UI以来计算工作程序内部的更改。您可以考虑使用以下流程：
如果有很多变化和一棵小树，这将会更快。如果它是一棵大树并且几乎没有变化，只需在真实DOM树的副本中进行本地更改就会更快，然后一次更新DOM。
同时阅读googles网站有关网页速度的信息：
https://code.google.com/speed/articles/
特别是这篇文章：
答案 1 :(得分：0)
在使用各种网络技术3年后，我认为我终于在两种方法之间取得了很好的平衡：虚拟DOM
像vdom，Elm，mithril.js这样的库，以及Facebook React在某种程度上跟踪实际DOM的精简抽象，找出需要更改的内容，并尝试应用尽可能小的DOM更改。
e.g。