在 dom 变慢并变得不稳定之前，你可以拥有多少个 div？
我正在开发一个 jQtouch 应用程序，通过 ajax 完成的每个请求都会在文档中为加载的内容创建一个新的 div。任何时候仅显示一个 div。
在应用程序开始变得无响应且缓慢之前，我可以拥有多少个 div？
有人对此有什么想法吗？
编辑：它是一个在 Safari 上运行的 iPad 应用程序，它的内容少于 1000 个 div，内容非常基本
I am developing a jQtouch app and each request done via ajax creates a new div in the document for the loaded content. Only a single div is shown at any one time.
How many div's can I have before the app starts getting unresponsive and slow?
Anyone have any ideas on this?
EDIT: Its an iPad app running on Safari, and it would be less than 1000 div's with very basic content
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果不定义特定环境，就不可能回答您的问题。
即使如此，任何人告诉您的任何内容都只是猜测。您需要使用不同的浏览器和硬件对实际配置进行自己的测试。您还需要建立一些性能基准来确定“太慢”的含义。
Without defining a particular environment, it's not possible to answer your question.
And even then, anything anyone tells you is just a guess. You need to do your own testing on real-world configurations with different browsers and hardware. You'll also need to establish some performance benchmarks to decide what "too slow" even means.
我已经能够毫无问题地添加数千个 div。当然，取决于您之后要做什么，以及客户端计算机上的内存。其他人都是对的。
正如 Harpo 所说，10K 可能是一个不错的上限。有一次，我注意到从大约 4K div 开始出现速度问题，但从那时起硬件已经有所改进。
而且，正如 Neil N 所说，通过脚本添加 div 比拥有庞大的 HTML 源代码更好。
而且，为了回答 Harpo 的评论，“打破它”以便 JS 不会锁定页面并产生“页面运行缓慢”错误的一种方法是在每个“添加 div”例程的末尾调用一个计时器，计时器又再次调用您的“添加 div”函数。
现在，我的问题是：是否可以“绘画”，这样就不需要添加数千个 div？这可以通过某些浏览器的canvas标签来完成，但我认为在IE上使用VML（excanvas项目）是不可能的。或者是吗？我认为 VML 通过向 DOM 添加新元素来“绘制”，此时您也可以使用 DIV，除非它是一个简单的形状。
是否可以通过脚本更改图像的来源？ （当然，DOM 中的图像——不是服务器上的原始图像。）
I've been able to add several thousand divs without a problem. Depends on what you'll be doing afterwards, of course, and the memory on the client machine. Everyone else is right about that.
As Harpo said, 10K is probably a good ceiling. At one time, I noticed speed problems starting at about 4K divs, but hardware has improved since then.
And, as Neil N said, adding the divs via scripting is better than having a huge HTML source.
And, to answer Harpo's comment, one way to "break it up" so that JS doesn't lock the page and produce a "page is running slowly" error is to call a timer at the end of each "add a div" routine, and the timer in turn calls your "add a div" function again.
Now, MY question is: is it possible to "paint" so that you don't need to add thousands of divs? This can be done with the canvas tag with some browsers, but I don't think it's possible with VML (the excanvas project) on IE. Or is it? I think VML "paints" by adding new elements to the DOM, at which point you may as well use DIVs, unless it's a simple shape.
Is it possible to alter the source of an image via scripting? (the image in the DOM, of course -- not the original image on the server.)
我曾经在屏幕上同时显示过数万个甚至十万个 div。
性能的好坏取决于：
从 HTML 解析还是在 JavaScript 中动态生成？
从 HTML 解析意味着您有一个大型 html 源，这可能会导致浏览器挂起。即使在所有 JS 浏览器中最慢的 Internet Explorer 上，用 JS 生成的速度也快得出奇。
I've had tens of thousands, maybe even a hundred thousand divs, on screen at once.
Performance is either fine, or bad, depending on:
Parsed from HTML or generated Dynamically in JavaScript?
Parsed from HTML means you have a LARGE html source, and this can make browsers hang. Generated in JS is surprisingly fast, even on Internet Explorer, which is the slowest of all browsers for JS.
老实说，如果您确实需要这个问题的绝对答案，那么您可能需要重新考虑您的设计。
这里给出的答案不会是正确的，因为它取决于许多特定于您的应用程序的因素。例如，CSS 的大量使用与少量使用、div 的大小、每个 div 所需的实际图形渲染量、目标浏览器/平台、DOM 事件侦听器的数量等。
仅仅因为您可以，并不意味着您应该这样做！ :-)
To be honest, if you really need an absolute answer to this question, then you might want to reconsider your design.
No answer given here will be right, as it depends upon many factors that are specific to your application. E.g. heavy vs. little CSS use, size of the divs, amount of actual graphics rendering required per div, target browser/platform, number of DOM event listeners etc..
Just because you can doesn't mean that you should! :-)
正如其他人所说，确实没有答案。
但是，在有关 Google Maps API 版本 3 的演讲中，演讲者提出了数字
http://code.google.com/apis/maps/documentation/javascript/< /a>
As others have said, there's really no answer.
However, in this talk about the Google Maps API version 3, the speaker brings up the number ten thousand several times, as a basic threshold for browser unhappiness.
http://code.google.com/apis/maps/documentation/javascript/