how many div's can you have before the dom slows and becomes unstable?

Question

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

Fargone

Test. Then you'll know. – Propend

Answer 1

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! :-)

Ruel

Answer 2

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.

Auditorium

Interesting... that makes sense, but in my experience, nothing freezes the browser like a lot of javascript. So the challenge is to break up the generation scrip and make sure it yields to the UI in between. – Torticollis

Indeed parsed JS is surprinsingly fast! – Emulate

Answer 3

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/

Torticollis

It is from the unnamed Dao // That Heaven and Earth sprang // The named is but // The Mother of the ten thousand creatures. – Suckow

Answer 4

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.

Sills

Answer 5

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.)

Murphy