Walk me through what actually happens in the event loop when you call await inside a click handler.

The handler runs synchronously until it hits await, then it hands control back to the browser and schedules the rest of the function as a microtask. Once the awaited promise settles, that continuation goes on the microtask queue, which drains completely after the current task and before the next timer or paint. So await never blocks the main thread; it splits the function in two.

Sure. The handler starts on the main thread like any other function, and everything up to the first await runs synchronously. At the await, the function suspends and returns a promise to its caller, so the browser gets the thread back and can paint. When the awaited promise resolves, the remainder of the function is pushed onto the microtask queue, not the task queue. That matters because microtasks drain fully before the browser takes the next timer or the next frame, so a long chain of promise resolutions can still block rendering even though nothing is technically synchronous. The practical version of this bit me on a dashboard I worked on. We were awaiting inside a for loop over about 300 rows, so every request waited for the one before it and the page took 12 seconds to fill. Switching to Promise.all with a small concurrency limit dropped it under a second. Same code, same thread, completely different behavior.