The Async Await Episode I Promised

Async/await matters because it turns JavaScript’s inherently asynchronous behavior—driven by the event loop—into code that reads like straight-line logic, without losing the performance benefits of non-blocking execution. The core idea starts with how browsers and Node.js run a single-threaded event loop: synchronous code runs immediately, while asynchronous work gets queued and later resumed. Crucially, the event loop distinguishes between macro tasks (like setTimeout/setInterval) and micro tasks (like fulfilled promises). Micro tasks run before the next event loop cycle begins, which can reorder execution in ways that surprise people who expect “line by line” behavior.

A simple example makes the point: console.log runs first, setTimeout(0) gets queued for a later macro task, a promise resolution is queued into the micro task queue, and then the final synchronous console.log runs. Even when the setTimeout callback was queued earlier, the promise’s micro task executes first because it has higher priority. That priority model explains why promises feel “faster” than timers and why understanding the event loop is the foundation for using async/await correctly.

From there, the transcript walks through promises as the underlying mechanism. APIs like fetch return promises, and promise chaining lets results flow through steps such as mapping a response to JSON. A single catch at the end can handle errors anywhere in the chain, avoiding the “one error handler per callback” problem common in callback-based code.

The lesson then targets a frequent misconception: wrapping heavy work in a promise doesn’t automatically move it off the main thread. Creating a promise and resolving it later still involves synchronous execution during promise creation; a CPU-blocking loop can freeze the program regardless. To avoid blocking, the expensive work must be structured so that synchronous execution completes first, and only then does the promise resolve—demonstrated by moving the loop into a resolved promise callback so the initial synchronous logs happen immediately.

With that groundwork, async/await is presented as syntactic sugar over promises. Marking a function as async makes it return a promise; using await pauses that function until the awaited promise resolves, letting developers write multi-step asynchronous flows without deep then chains. A fruit-and-smoothie example shows how values can be stored in variables after awaiting, making it easier to share results across steps.

The most important performance warning follows: awaiting sequentially can accidentally serialize independent operations. If two promises don’t depend on each other, awaiting them one after the other adds unnecessary latency. The fix is to start them concurrently (e.g., by collecting promises and using Promise.all) and then await the combined result. Error handling also becomes cleaner: try-catch around awaited calls replaces chained catch logic, with control flow determined by whether errors are rethrown or converted into fallback return values.

Finally, the transcript highlights practical patterns and pitfalls: async/await inside map or forEach doesn’t behave like a “pause-and-iterate” loop, so concurrency may happen unintentionally. When sequential behavior is required, a traditional for loop with await inside it is the right tool; when concurrency is desired, Promise.all and even for-await-of patterns can keep code concise. The takeaway is straightforward: async/await improves readability, but performance and correctness still depend on event loop timing, concurrency choices, and loop semantics.