Expliquez-moi ce qui se passe vraiment dans l'event loop quand vous appelez await à l'intérieur d'un gestionnaire de clic.

Le gestionnaire s'exécute de façon synchrone jusqu'à ce qu'il rencontre await, puis il rend la main au navigateur et planifie le reste de la fonction comme une microtâche. Une fois la promesse attendue résolue, cette continuation part dans la file des microtâches, qui se vide entièrement après la tâche en cours et avant le prochain timer ou le prochain rendu. Donc await ne bloque jamais le thread principal ; il coupe la fonction en deux.

Bien sûr. Le gestionnaire démarre sur le thread principal comme n'importe quelle fonction, et tout ce qui précède le premier await s'exécute de façon synchrone. Au await, la fonction se suspend et renvoie une promesse à son appelant, donc le navigateur récupère le thread et peut peindre. Quand la promesse attendue se résout, le reste de la fonction est poussé dans la file des microtâches, pas dans la file des tâches. Ça compte parce que les microtâches se vident entièrement avant que le navigateur ne prenne le prochain timer ou la prochaine frame, donc une longue chaîne de résolutions de promesses peut quand même bloquer le rendu alors que rien n'est techniquement synchrone. La version concrète m'est tombée dessus sur un tableau de bord. On faisait un await dans une boucle for sur environ 300 lignes, donc chaque requête attendait la précédente et la page mettait 12 secondes à se remplir. Passer à Promise.all avec une petite limite de concurrence a fait descendre ça sous la seconde. Même code, même thread, comportement complètement différent.