Pythoneer

I am writing a heavy JavaScript application and now I can understand the advantages it had doing embedded programming :-).

The simple task I ordered my browser to process via JavaScript, was that it shows this image and then starts doing the real work, which will take long, so indicate that first by showing the image. Nothing easier than that, set style.display = “inline” and go for it. But to my surprise the image was never shown, may be sometimes for a very very short time at the end, when everything was already over. That lead me to investigate what really happens there. And I wrote a little script which basically does those two things in this order:

1. show the image, that indicates that something will be done and the user shall wait
2. do the task that takes really long

The resulting script is here.

The result I saw was that the rendering obviously does not happen in real time, as the script would let you assume. It is “put off” to a later point in time and while the heavy-load-task is executed the rendering does not take place. In my case the heavy-load-task was just looping over thousands of calls to document.getElementById, since there was no setTimeout or anything alike used in this loop I expected the browser to be busy for a while, of course. But that the showing of the image was not done until the loop had ended was a surprise to me. Imho it makes clear that the browser either updates his DOM tree very quickly but the rendering engine doesn’t get time to update the screen or that the DOM changes are put in some queue and processed later, which would be very difficult and cause race conditions easily. So I think the first thing happens. For programming reliable JavaScript, especially DHTML this knowledge is extremely valueable but the fact is very obstructive.
That strengthens that a poorly implemented JavaScript can block the browser easily (we all knew that). But now in the times of AJAX JavaScript becomes more and more a thing that is used heavily and the browsers don’t seem to be prepared for this load yet.

No browser is prepared as my tests have shown. This makes me doubt that I am just doing it right and may be I am testing something irrelevant or may be in the wrong way, but I doubt it.
I tried all the relevant browsers I have available on Mac OS X those are the times it takes them to finish the heavy-load-task and to finally show the image (or hide as in the example above).

Firefox 1.5 - about 2 seconds
Safari 2.0.3 (comes with Mac OS X 10.4.6) - at least 10 seconds
Safari nightly build (from http://nightly.webkit.org/builds) - about 0.4 seconds
Opera 8.54 - about 0.7 seconds

The heavy-load-task in the script is looking through the DOM tree and searching for 30.000 elements (you can change this number), which don’t exist. But the DOM tree is actually very small (just have a look at the source) that it is even more surprising that it takes even about 10 seconds in Safari, but fortunately the new version of Safari will be significantly faster!
And by the way, it doesn’t matter if I am looking for the same node every time in the loop or for a different node every time, I tried it (there is no caching of the nodes obviously).

Or did I just do something wrong or misunderstand something?
Sharper minds: please let me learn!