Erklär mir Schritt für Schritt, was in der Event Loop tatsächlich passiert, wenn du in einem Click-Handler await aufrufst.

Der Handler läuft synchron, bis er auf await trifft, gibt dann die Kontrolle an den Browser zurück und plant den Rest der Funktion als Microtask ein. Sobald das erwartete Promise abgeschlossen ist, landet diese Fortsetzung in der Microtask-Queue, die nach der aktuellen Task und vor dem nächsten Timer oder Paint komplett geleert wird. await blockiert den Main Thread also nie; es teilt die Funktion in zwei Teile.

Klar. Der Handler startet wie jede andere Funktion auf dem Main Thread, und alles bis zum ersten await läuft synchron. Beim await wird die Funktion ausgesetzt und gibt ein Promise an ihren Aufrufer zurück, der Browser bekommt also den Thread zurück und kann painten. Wenn das erwartete Promise auflöst, wird der Rest der Funktion in die Microtask-Queue geschoben, nicht in die Task-Queue. Das ist wichtig, weil Microtasks vollständig geleert werden, bevor der Browser den nächsten Timer oder den nächsten Frame nimmt, eine lange Kette von Promise-Auflösungen kann das Rendern also blockieren, obwohl technisch nichts synchron ist. Die praktische Variante hat mich auf einem Dashboard erwischt, an dem ich gearbeitet habe. Wir haben in einer for-Schleife über rund 300 Zeilen awaitet, jeder Request hat also auf den vorherigen gewartet und die Seite brauchte 12 Sekunden. Der Wechsel auf Promise.all mit einem kleinen Concurrency-Limit hat es unter eine Sekunde gedrückt. Gleicher Code, gleicher Thread, komplett anderes Verhalten.