Kleine unwichtige Anmerkung: setTimeout startet keinen eigenen Thread. In JavaScript gibt es _immer_ nur einen Thread. Das sieht man, wenn ein Script gerade noch läuft, während das Timeout schon lange abgelaufen ist. Die Callback-Funktion des Timeouts wird nämlich erst ausgeführt, wenn das andere Script fertig abgearbeitet wurde.

Ausprobieren kann man das mit so sinnlosem Code wie diesem:

var d = (new Date()).getTime();
setTimeout(function() {
  alert("es sind " + ((new Date()).getTime() - d) + "millisekunden vergangen";
}, 100);


// sleep(500), nur mit verbrannter CPU:
while((new Date()).getTime() - d < 500)
  ;

Ich weiß jetzt nur einen Fall, in dem man das tatsächlich praktisch anwenden kann: ein Timeout von 0 Millisekunden. Damit kann man das eigene Script ans Ende der Warteschlange aller auszuführender Scripte verschieben. Nützlich ist das z.B. wenn es viele Event-Handler (addEventListener) gibt und man sicherstellen will, nach den anderen dran zu sein.

Beispiel-Code:

var someGlobalVariable = "bla";


document.addEventListener("load", function(event) {
  window.someGlobalVariable = "blubb";
}, false);
document.addEventListener("load", function(event) {
  window.setTimeout(function() {
    alert(someGlobalVariable);
  }, 0);
}, false);

Thread war das falsche Wort, ich habe es geändert. Ich meinte, dass der Ausführungskontext verworfen wird und der Code ohne Verbindung zum vorigen Kontext im globalen Kontext ausgeführt wird. Dem kann man nur mit Closures entgegenwirken.