“现代”是因为这个定义可能随着时间的推移而改变(特指桌面浏览器)
“处理”是因为这可能会根据机器配置/内存而有所不同,但特指一般使用情况。
这个问题是针对我正在解决的一个涉及大型数据集的特定问题而提出的。基本上,每当对特定数据集进行更改时,我都会收到完整的数据集,并且必须在浏览器中呈现此数据。
例如,在websocket上,我会收到一个推送事件,告诉我数据集有更改,然后我必须通过获取现有DOM元素、复制它、使用类名或其他元素标识符填充元素中的数据,并将其添加回DOM来呈现此数据集的HTML。
请注意,此数据集中的任何对象(JSON)可能有多达1000个以上的子对象,并且可能有多达10,000个以上的父对象,因此您可以看到返回的数据集可能向上达到1,000,000 => 10,000,000个数据点或更多。
现在有趣的部分是当我必须呈现这些东西时。对于每个数据点,可能会使用3或4个标记来呈现和样式化数据,并且可能会为其中任何标记设置事件侦听器(也许在父容器上使用委托减轻负担)。
总而言之,可能会有大量需要渲染的传入信息,我正在尝试找出处理此情况的最佳方法。理想情况下,您只需要为发生更改的单个数据点呈现更改,而不是重新呈现整个集合,但由于后端的设计方式,这可能不是一个选项。我的主要关注点是了解浏览器/DOM的限制,并通过前端的视角来看待这个问题。确实应该在后端进行一些更改(数据设计、缓存、分页),但这不是重点。这不是HTML/DOM的典型用例,因为我知道它们有限制,但它们到底是什么?我们仍然被限制在大约3000-4000个元素吗?
我有一些关于这个问题的相关 子问题,我正在积极地 寻找 答案。但我认为与stackoverflow社区分享一些想法并尝试汇集一些关于这个问题的信息会很好。 现代浏览器可以处理多少个DOM元素才能保持良好的性能? 如何对浏览器可以处理的DOM元素数量进行基准测试?
除了分页之外,处理需要呈现的大型数据集的一些策略是什么?
对于从数据/JSON渲染HTML(在前端)来说,像mustache和handlebars这样的模板框架是否比使用jQuery或正则表达式更具性能?