Hallo Jo, eine Frage ist noch offengeblieben: warum gibt's `window.window` und `window.self`. Ob sie BEIDE mit HTML 5 definiert wurden oder ob es einen davon auch schon früher gab (und vielleicht der eine Microsoft war und der andere Netscape), das kann ich Dir nicht mehr sagen. Eine Spec, die sie nennt, kenne ich erst ab HTML 5. Vorsicht beim Googeln - man findet sogar in Referenz-Werken wie Stackoverflow ganz oben und hochbepunktet Aussagen wie „das ist das selbe“. Nein. Ist es nicht. `window.window` sollte offensichtlich sein; Das Window-Objekt ist der Container für die globalen Variablen, und `window` ist eine globale Variable. Ganz einfach. D.h. eigentlich ist es nicht GANZ so einfach, aber wenn Du das wirklich wissen willst, guck unter [WindowProxy](https://html.spec.whatwg.org/multipage/window-object.html#windowproxy) in die Spec von HTML. `window.self` wird verständlich, wenn man neuere JavaScript-Techniken betrachtet. Zunächst mal: Das, was wir so locker "Klassen" nennen, sind in der HTML Spec zumeist INTERFACES. D.h. da ist irgendein Objekt, implementiert durch irgendeine tief-technische, umgebungsspezifische Klasse, aber es verspricht Dir: "Ich implementiere das Window-Interface, also kannst Du Dich darauf verlassen, dass ich alles tun kann, was ein Window tun können muss". Es gibt noch jemand anderen, der Dich so treuherzig anschaut, und das ist das [`WorkerGlobalScope`](https://html.spec.whatwg.org/multipage/workers.html#the-workerglobalscope-common-interface) Interface. Wenn Du einen WebWorker abspaltest, dann braucht der auch einen globalen Scope, und aus diversen Gründen ist das NICHT das Window-Objekt. Sondern etwas eigenes, eben ein `WorkerGlobalScope`. Beide - `Window` und `WorkerGlobalScope` - erben vom DOM-Interface [`EventTarget`](https://dom.spec.whatwg.org/#interface-eventtarget), und viele Dinge, die man bei der Kommunikation zwischen Vordergrund-Task und Worker-Tasks tut, basieren auf Messages und Events. Nun möchte man beim Programmieren der Infrastruktur dafür nicht alles zweimal schreiben, und jetzt kommt `self` ins Spiel. Es wäre echt irreführend, wenn ein `WorkerGlobalScope` sich selbst über eine globale Variable `window` referenzieren würde. `self` ist da deutlich klarer. „I bims, dein globaler Kontext“. Sowohl `Window` als auch `WorkerGlobalScope` enthalten `self` und stellen damit im Wesentlichen ihren kleinsten gemeinsamen Nenner bereit: das `EventTarget`. Es ist de facto noch etwas mehr, bei Interesse folge den Links zur Spec. Wenn Du nun Messaging zwischen deinen Threads programmierst, nimmst Du immer `self.addEventListener` statt `window.addEventListener` und alles ist gut. Lange Rede, kurzer Sinn: Wenn Du ohne WebWorker arbeitest, kannst Du `window` und `self` synonym verwenden. Setzt Du WebWorker ein, muss der im Worker ausgeführte Code `self` verwenden, um auf den globalen Kontext zuzugreifen. `window` gibt es dort nicht. D.h. du könntest abfragen `if (self.window) { ... }` um zu erkennen, ob dein Code im Window-Thread oder in einem Worker-Thread abgefragt wird. Es könnte also sinnvoll sein, sich folgendes anzugewöhnen: - immer `self` verwenden für das globale Objekt - wenn man eine Closure-fähige Kopie von `this` braucht, dafür NICHT `self` verwenden, sondern etwas anderes wie `that` oder `me`. Notiz an mich: Du hast im Büro ein Todo, Rolf! _Rolf_ -- sumpsi - posui - clusi

Hallo Jo, eine Frage ist noch offengeblieben: warum gibt's `window.window` und `window.self`. Ob sie BEIDE mit HTML 5 definiert wurden oder ob es einen davon auch schon früher gab (und vielleicht der eine Microsoft war und der andere Netscape), das kann ich Dir nicht mehr sagen. Eine Spec, die sie nennt, kenne ich erst ab HTML 5. Vorsicht beim Googeln - man findet sogar in Referenz-Werken wie Stackoverflow ganz oben und hochbepunktet Aussagen wie „das ist das selbe“. Nein. Ist es nicht. `window.window` sollte offensichtlich sein; Das Window-Objekt ist der Container für die globalen Variablen, und `window` ist eine globale Variable. Ganz einfach. D.h. eigentlich ist es nicht GANZ so einfach, aber wenn Du das wirklich wissen willst, guck unter [WindowProxy](https://html.spec.whatwg.org/multipage/window-object.html#windowproxy) in die Spec von HTML. `window.self` wird verständlich, wenn man neuere JavaScript-Techniken betrachtet. Zunächst mal: Das, was wir so locker "Klassen" nennen, sind in der HTML Spec zumeist INTERFACES. D.h. da ist irgendein Objekt, implementiert durch irgendeine tief-technische, umgebungsspezifische Klasse, aber es verspricht Dir: "Ich implementiere das Window-Interface, also kannst Du Dich darauf verlassen, dass ich alles tun kann, was ein Window tun können muss". Es gibt noch jemand anderen, der Dich so treuherzig anschaut, und das ist das [`WorkerGlobalScope`](https://html.spec.whatwg.org/multipage/workers.html#the-workerglobalscope-common-interface) Interface. Wenn Du einen WebWorker abspaltest, dann braucht der auch einen globalen Scope, und aus diversen Gründen ist das NICHT das Window-Objekt. Sondern etwas eigenes, eben ein `WorkerGlobalScope`. Beide - `Window` und `WorkerGlobalScope` - erben vom DOM-Interface [`EventTarget`](https://dom.spec.whatwg.org/#interface-eventtarget), und viele Dinge, die man bei der Kommunikation zwischen Vordergrund-Task und Worker-Tasks tut, basieren auf Messages und Events. Nun möchte man beim Programmieren der Infrastruktur dafür nicht alles zweimal schreiben, und jetzt kommt `self` ins Spiel. Es wäre echt irreführend, wenn ein `WorkerGlobalScope` sich selbst über eine globale Variable `window` referenzieren würde. `self` ist da deutlich klarer. „I bims, dein globaler Kontext“. Sowohl `Window` als auch `WorkerGlobalScope` enthalten `self` und stellen damit im Wesentlichen ihren kleinsten gemeinsamen Nenner bereit: das `EventTarget`. Es ist de facto noch etwas mehr, bei Interesse folge den Links zur Spec. Wenn Du nun Messaging zwischen deinen Threads programmierst, nimmst Du immer `self.addEventListener` statt `window.addEventListener` und alles ist gut. _Rolf_ -- sumpsi - posui - clusi