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