"现代",因为该定义可能会随着时间而改变(具体而言,我指的是桌面浏览器)
"处理"因为根据机器配置/内存可能会有所不同,但具体而言我指的是一般用例.
对于我正试图解决的涉及大型数据集的特定问题,我想到了这个问题.
基本上,每当对特定数据集进行更改时,我都会返回完整的数据集,并且必须在浏览器中呈现此数据.
例如,在websocket上我得到一个推送事件,告诉我数据集有变化,然后我必须通过抓取现有的DOM元素,复制它,使用类名用这个集合中的数据填充元素来在HTML中呈现这个数据集或其他元素标识符,然后将其添加回DOM.
请记住,此数据集中的任何对象(JSON)可能包含多达1000个以上的子对象,并且可能有多达10,000个以上的父对象,因此您可以看到可能存在返回的数据集向上的实例接近1,000,000 => 10,000,000个数据点或更多.
现在有趣的部分来了,当我必须渲染这些东西.对于每个数据点,可能有3或4个标记用于呈现和样式化数据,并且可能有任何这些标记的事件侦听器(可能在父容器上使用委托来减轻事情).
总结一下,可能会有很多需要呈现的传入信息,我正试图找出处理这种情况的最佳方法.
理想情况下,您只想渲染具有更改而不是重新渲染整个集合的单个数据点的更改,但由于后端的设计方式,这可能不是一个选项.
我主要关心的是了解浏览器/ DOM的局限性,并通过前端的镜头来看待这个问题.在后端肯定会发生一些变化(数据设计,缓存,分页),但这不是重点.
这不是HTML/DOM 的典型用例,因为我知道它有局限性,但究竟是什么呢？我们仍然限制在大约3000-4000元素？
我有一些相关的 子问题,我正在积极地 查找 ,但我认为与stackoverflow社区的其余部分分享一些想法并尝试将有关此问题的信息汇总在一起会很好.
现代浏览器在开始变慢/无响应之前可以处理的"合理"数量的DOM元素是什么？
如何对浏览器可以处理的DOM元素数量进行基准测试？
有哪些策略可以处理需要渲染的大型数据集(除了分页)？
与使用jQuery或正则表达式相比,使用数据/ json(在前端)渲染html等模板框架(如胡子和把手)的性能更高吗？
我正在开发一个jQtouch应用程序,每个通过ajax完成的请求都会在文档中为加载的内容创建一个新的div.任何时候只显示一个div.
在应用程序开始变得反应迟钝之前,我可以拥有多少div？
任何人对此都有任何想法？
编辑:它是一个在Safari上运行的iPad应用程序,它将不到1000个div,具有非常基本的内容