## Introduction: Why Asynchronous JavaScript Matters JavaScript is single-threaded. It has one call stack, one memory heap, and can only do one thing at a time. Yet somehow, JavaScript applications handle thousands of concurrent operations: fetching data from APIs, reading files, responding to user clicks, running timers, all seemingly at once. How does a single-threaded language handle all this without freezing? The answer is asynchronous programming, and mastering it is essential for any JavaScript developer. ### What Makes JavaScript Different In languages like Java or Python, you can spawn multiple threads to handle concurrent operations. JavaScript doesn't have that luxury in its core execution model. Instead, it uses an event-driven, non-blocking architecture that lets it delegate work and continue executing without waiting. When you make an API call, JavaScript doesn't sit idle waiting for the response. It hands off the request to the browser (or Node.js runtime), continues executing other code, and handles the response when it arrives. This is the essence of asynchronous JavaScript. ### Real-World Async Operations Almost everything interesting in JavaScript is asynchronous: - **Network requests**: Fetching data from APIs, uploading files - **Timers**: setTimeout, setInterval, requestAnimationFrame - **User interactions**: Event listeners waiting for clicks, keypresses - **File operations**: Reading/writing files in Node.js - **Database queries**: Any interaction with a database - **Web Workers**: Communication with background threads If these operations were synchronous (blocking), your UI would freeze every time you made an API call. Imagine clicking a button and the entire page becoming unresponsive for 2 seconds while waiting for a server response. That's what synchronous network requests would look like. ### The Evolution of Async JavaScript Asynchronous JavaScript has evolved significantly: **Era 1: Callbacks (1995+)** The original pattern. Pass a function to be called when an operation completes. **Era 2: Promises (ES2015/ES6)** A cleaner abstraction representing a future value. Chainable and composable. **Era 3: Async/Await (ES2017)** Syntactic sugar over Promises that makes async code look synchronous. Each evolution solved problems with the previous approach while building on the same underlying mechanisms. ### What You'll Learn By the end of this guide, you will: - Understand how the event loop enables async JavaScript - Know why callbacks led to "callback hell" and how Promises solved it - Master Promise creation, chaining, and composition - Use async/await to write clean, readable async code - Handle errors properly in both Promise chains and async functions - Implement advanced patterns like retry logic, timeouts, and cancellation - Avoid common pitfalls that trip up even experienced developers - Answer async-related interview questions with confidence Let's start with the foundation: the event loop. --- ## The Foundation: Understanding the Event Loop Before diving into Promises, you need to understand how JavaScript handles asynchronous operations. The event loop is the mechanism that makes it all possible. ### The Mental Model Picture JavaScript as a restaurant with a single chef (the main thread). The chef can only cook one dish at a time. But the restaurant handles many orders simultaneously. How? - **Call Stack**: The chef's current task. Whatever's being cooked right now. - **Web APIs / Node APIs**: The kitchen staff. They handle time-consuming tasks (timers, network requests) separately. - **Task Queue (Callback Queue)**: Completed orders waiting to be served. - **Microtask Queue**: VIP orders that get priority (Promise callbacks). - **Event Loop**: The manager who checks if the chef is free and assigns the next task. ### The Components in Detail **Call Stack** The call stack is where JavaScript keeps track of function execution. When you call a function, it's pushed onto the stack. When it returns, it's popped off. ```js function multiply(a, b) { return a * b; } function square(n) { return multiply(n, n); } function printSquare(n) { const result = square(n); console.log(result); } printSquare(4); ``` The stack during execution: 1. `printSquare(4)` pushed 2. `square(4)` pushed 3. `multiply(4, 4)` pushed 4. `multiply` returns 16, popped 5. `square` returns 16, popped 6. `console.log(16)` pushed 7. `console.log` completes, popped 8. `printSquare` completes, popped The stack is now empty. **Web APIs / Runtime APIs** When you call `setTimeout`, `fetch`, or add an event listener, JavaScript hands that work to the browser (or Node.js runtime). These APIs run outside the main JavaScript thread. ```js console.log("Start"); setTimeout(() => { console.log("Timeout callback"); }, 1000); console.log("End"); ``` What happens: 1. `console.log("Start")` executes immediately 2. `setTimeout` is called, the timer is handed to the Web API 3. `console.log("End")` executes immediately 4. (1 second passes in the Web API) 5. The callback is moved to the task queue 6. Event loop sees the stack is empty, moves callback to stack 7. `console.log("Timeout callback")` executes Output: ``` Start End Timeout callback ``` **Task Queue (Callback Queue)** When async operations complete, their callbacks are placed in the task queue. The event loop moves them to the call stack when the stack is empty. **Microtask Queue** This is crucial for understanding Promises. The microtask queue has higher priority than the task queue. After each task completes, the event loop drains the entire microtask queue before moving to the next task. Promise callbacks (`.then()`, `.catch()`, `.finally()`) go to the microtask queue, not the task queue. ### Event Loop in Action Let's trace through a more complex example: ```js console.log("1"); setTimeout(() => { console.log("2"); }, 0); Promise.resolve().then(() => { console.log("3"); }); console.log("4"); ``` Step by step: 1. `console.log("1")` - executes immediately, prints "1" 2. `setTimeout` callback - goes to task queue (even with 0ms delay) 3. `Promise.resolve().then()` callback - goes to microtask queue 4. `console.log("4")` - executes immediately, prints "4" 5. Call stack is now empty 6. Event loop checks microtask queue first - finds the Promise callback 7. `console.log("3")` - executes, prints "3" 8. Microtask queue is now empty 9. Event loop checks task queue - finds setTimeout callback 10. `console.log("2")` - executes, prints "2" Output: ``` 1 4 3 2 ``` This order trips up many developers. The Promise callback runs before the setTimeout callback, even though setTimeout was registered first. Microtasks always have priority. ### Why This Matters for Promises Understanding the microtask queue is essential because: 1. Promise callbacks are always asynchronous, even if the Promise is already resolved 2. Microtasks run before the next render, which can cause UI issues if you queue too many 3. Execution order questions are common in interviews 4. Debugging async code requires understanding when callbacks will run Here's another example that catches people off guard: ```js console.log("Script start"); setTimeout(() => { console.log("setTimeout"); }, 0); Promise.resolve() .then(() => { console.log("Promise 1"); }) .then(() => { console.log("Promise 2"); }); console.log("Script end"); ``` Output: ``` Script start Script end Promise 1 Promise 2 setTimeout ``` Both Promise callbacks run before setTimeout because each `.then()` adds to the microtask queue, and the entire microtask queue drains before moving to the task queue. --- ## The Callback Era (And Its Problems) Before Promises, callbacks were the only way to handle asynchronous operations in JavaScript. Understanding callbacks and their limitations helps you appreciate why Promises were created. ### How Callbacks Work A callback is simply a function passed as an argument to another function, to be executed later. ```js function fetchData(callback) { setTimeout(() => { const data = { id: 1, name: "Alice" }; callback(data); }, 1000); } fetchData((data) => { console.log("Received:", data); }); console.log("Fetching data..."); ``` Output: ``` Fetching data... Received: { id: 1, name: "Alice" } ``` This works fine for simple cases. The problem arises when you need to chain multiple async operations. ### Callback Hell (The Pyramid of Doom) Imagine you need to: fetch a user, then fetch their posts, then fetch comments on the first post. ```js getUser(userId, (error, user) => { if (error) { handleError(error); } else { getPosts(user.id, (error, posts) => { if (error) { handleError(error); } else { getComments(posts[0].id, (error, comments) => { if (error) { handleError(error); } else { processComments(comments, (error, result) => { if (error) { handleError(error); } else { console.log("Final result:", result); } }); } }); } }); } }); ``` This is callback hell. The code: - Nests deeper with each async operation - Has repetitive error handling at every level - Is hard to read and maintain - Makes control flow difficult to follow ### The Inversion of Control Problem With callbacks, you hand control of your code to another function. You're trusting that function to: - Call your callback exactly once - Call it with the correct arguments - Call it at the right time - Handle errors appropriately What if the function calls your callback twice? Or never calls it? You have no control. ```js // You're trusting thirdPartyLibrary to behave correctly thirdPartyLibrary.doSomething((result) => { // Will this be called? Once? Multiple times? Who knows! processResult(result); }); ``` ### Error Handling Difficulties The Node.js convention of error-first callbacks helps, but it's still problematic: ```js fs.readFile("file.txt", (err, data) => { if (err) { // Handle error... but what if we forget this check? return; } // Use data }); ``` Errors don't propagate automatically. You must check for errors at every step. Forget one check, and errors get swallowed silently. ### Why We Needed Something Better Callbacks work, but they have fundamental issues: 1. **Readability**: Deeply nested code is hard to follow 2. **Error handling**: Manual at every level, easy to miss 3. **Composability**: Hard to combine multiple async operations 4. **Trust**: Inversion of control puts you at the mercy of callback-callers Promises were designed to solve all of these problems. --- ## Promises: The Basics A Promise is an object representing the eventual completion (or failure) of an asynchronous operation and its resulting value. ### The Three States A Promise is always in one of three states: 1. **Pending**: Initial state, operation not yet complete 2. **Fulfilled**: Operation completed successfully, Promise has a value 3. **Rejected**: Operation failed, Promise has a reason (error) Once a Promise is fulfilled or rejected, it's "settled" and cannot change state again. ``` pending | +-----+-----+ | | fulfilled rejected (with value) (with reason) ``` ### Creating a Promise The `Promise` constructor takes an executor function with two parameters: `resolve` and `reject`. ```js const promise = new Promise((resolve, reject) => { // Do some async operation const success = true; if (success) { resolve("Operation succeeded!"); } else { reject(new Error("Operation failed!")); } }); ``` A more realistic example with a timer: ```js function delay(ms) { return new Promise((resolve) => { setTimeout(() => { resolve(`Waited ${ms}ms`); }, ms); }); } delay(1000).then((message) => { console.log(message); // "Waited 1000ms" (after 1 second) }); ``` ### TypeScript: Typing Promises In TypeScript, Promises are generic. You specify the type of the resolved value: ```typescript function fetchUser(id: number): Promise { return new Promise((resolve, reject) => { // fetch user... const user: User = { id, name: "Alice" }; resolve(user); }); } interface User { id: number; name: string; } // TypeScript knows `user` is of type User fetchUser(1).then((user) => { console.log(user.name); }); ``` If a Promise can reject, the rejection is typically an `Error`, but TypeScript doesn't enforce rejection types by default. ### Consuming Promises: .then(), .catch(), .finally() **`.then(onFulfilled, onRejected)`** Attaches callbacks for when the Promise settles. ```js promise.then( (value) => { console.log("Fulfilled with:", value); }, (reason) => { console.log("Rejected with:", reason); } ); ``` Usually, you'll use `.then()` for success and `.catch()` for errors: ```js promise .then((value) => { console.log("Success:", value); }) .catch((error) => { console.log("Error:", error); }); ``` **`.catch(onRejected)`** A shorthand for `.then(undefined, onRejected)`. Handles rejections. ```js promise.catch((error) => { console.error("Something went wrong:", error); }); ``` **`.finally(onFinally)`** Runs when the Promise settles, regardless of outcome. Useful for cleanup. ```js promise .then((value) => { console.log("Success:", value); }) .catch((error) => { console.error("Error:", error); }) .finally(() => { console.log("Cleanup: hiding loading spinner"); }); ``` The `.finally()` callback receives no arguments and doesn't affect the Promise's value. ### Static Methods for Creating Promises **`Promise.resolve(value)`** Creates a Promise that's immediately fulfilled with the given value. ```js const resolved = Promise.resolve(42); resolved.then((value) => console.log(value)); // 42 ``` **`Promise.reject(reason)`** Creates a Promise that's immediately rejected with the given reason. ```js const rejected = Promise.reject(new Error("Something failed")); rejected.catch((error) => console.log(error.message)); // "Something failed" ``` These are useful for returning Promises from functions that might complete synchronously: ```typescript function getCachedUser(id: number): Promise { const cached = cache.get(id); if (cached) { return Promise.resolve(cached); // Return Promise even for sync case } return fetchUserFromAPI(id); // Returns a Promise } ``` ### The Promise Lifecycle Let's trace through a complete example: ```js console.log("1. Creating promise"); const promise = new Promise((resolve, reject) => { console.log("2. Executor runs synchronously"); setTimeout(() => { console.log("4. Resolving promise"); resolve("Success!"); }, 1000); }); console.log("3. Adding .then() handler"); promise.then((value) => { console.log("5. Handler called with:", value); }); console.log("6. Script continues"); ``` Output: ``` 1. Creating promise 2. Executor runs synchronously 3. Adding .then() handler 6. Script continues (1 second later) 4. Resolving promise 5. Handler called with: Success! ``` Key observations: - The executor function runs synchronously when the Promise is created - `.then()` registers a callback but doesn't block - The callback runs asynchronously, after the Promise resolves --- ## How Promises Work Under the Hood Understanding Promise internals helps you predict execution order and debug tricky async issues. ### Promise States and Fate Every Promise has a **state** (pending, fulfilled, or rejected) and a **fate** (resolved or unresolved). - **Unresolved**: The Promise's outcome hasn't been determined yet - **Resolved**: The Promise's outcome is determined (either fulfilled, rejected, or locked in to another Promise) A Promise can be resolved but still pending. This happens when a Promise resolves to another Promise: ```js const innerPromise = new Promise((resolve) => { setTimeout(() => resolve("inner"), 1000); }); const outerPromise = new Promise((resolve) => { resolve(innerPromise); // Resolved, but pending (waiting for innerPromise) }); outerPromise.then(console.log); // "inner" (after 1 second) ``` ### The Microtask Queue and Promises Promise callbacks always execute asynchronously, even if the Promise is already settled: ```js const resolvedPromise = Promise.resolve("Already done"); console.log("Before .then()"); resolvedPromise.then((value) => { console.log("Inside .then():", value); }); console.log("After .then()"); ``` Output: ``` Before .then() After .then() Inside .then(): Already done ``` Even though `resolvedPromise` is already fulfilled, the `.then()` callback goes to the microtask queue and runs after the current synchronous code completes. ### Why .then() Always Returns a New Promise Every call to `.then()` creates and returns a new Promise. This enables chaining. ```js const promise1 = Promise.resolve(1); const promise2 = promise1.then((x) => x + 1); const promise3 = promise2.then((x) => x + 1); console.log(promise1 === promise2); // false console.log(promise2 === promise3); // false promise3.then(console.log); // 3 ``` The returned Promise: - Resolves with the return value of the callback - Rejects if the callback throws an error - "Adopts" another Promise if the callback returns a Promise ### Execution Order Deep Dive This is where it gets tricky. Let's trace through a complex example: ```js console.log("1"); setTimeout(() => console.log("2"), 0); Promise.resolve() .then(() => { console.log("3"); return Promise.resolve(); }) .then(() => console.log("4")); Promise.resolve().then(() => console.log("5")); console.log("6"); ``` Let's trace step by step: **Synchronous phase:** 1. `console.log("1")` → prints "1" 2. `setTimeout` callback → goes to task queue 3. First Promise chain `.then()` callback → goes to microtask queue (let's call it M1) 4. Second Promise `.then()` callback → goes to microtask queue (M2) 5. `console.log("6")` → prints "6" **Microtask phase (runs before any task):** 6. M1 runs: prints "3", returns `Promise.resolve()` 7. Because M1 returned a Promise, the next `.then()` waits for it (adds M3 to queue) 8. M2 runs: prints "5" 9. M3 runs: prints "4" **Task phase:** 10. setTimeout callback runs: prints "2" Output: ``` 1 6 3 5 4 2 ``` The key insight: when a `.then()` callback returns a Promise, the next `.then()` in the chain must wait for that Promise to settle, which introduces additional microtask queue cycles. ### Interview Classic: What's the Output? ```js Promise.resolve() .then(() => { console.log(0); return Promise.resolve(4); }) .then((res) => { console.log(res); }); Promise.resolve() .then(() => { console.log(1); }) .then(() => { console.log(2); }) .then(() => { console.log(3); }) .then(() => { console.log(5); }) .then(() => { console.log(6); }); ``` Output: `0, 1, 2, 3, 4, 5, 6` This is tricky! When the first chain returns `Promise.resolve(4)`, the Promise resolution procedure requires additional microtask cycles before the next `.then()` can run. Meanwhile, the second chain's callbacks keep executing. Don't worry if this feels confusing. The key takeaway is: **returning a Promise from `.then()` delays the next step in the chain.** --- ## Promise Chaining and Composition Chaining and composition are what make Promises powerful. Let's explore the patterns. ### Basic Chaining Each `.then()` returns a new Promise, allowing you to chain operations: ```js fetch("/api/user") .then((response) => response.json()) .then((user) => fetch(`/api/posts?userId=${user.id}`)) .then((response) => response.json()) .then((posts) => { console.log("User posts:", posts); }) .catch((error) => { console.error("Something failed:", error); }); ``` Compare this to the callback hell version. The flow is linear and readable. ### Returning Values vs. Returning Promises What you return from `.then()` determines the next Promise's value: **Return a value:** The next Promise resolves with that value. ```js Promise.resolve(1) .then((x) => x + 1) // returns 2 .then((x) => x * 2) // returns 4 .then(console.log); // logs 4 ``` **Return a Promise:** The next `.then()` waits for that Promise. ```js Promise.resolve(1) .then((x) => { return new Promise((resolve) => { setTimeout(() => resolve(x + 1), 1000); }); }) .then(console.log); // logs 2 after 1 second ``` **Return nothing (undefined):** The next Promise resolves with `undefined`. ```js Promise.resolve(1) .then((x) => { console.log(x); // 1 // no return statement }) .then(console.log); // logs undefined ``` ### Promise.all(): Parallel Execution Run multiple Promises in parallel and wait for all to complete: ```js const promise1 = fetch("/api/users"); const promise2 = fetch("/api/posts"); const promise3 = fetch("/api/comments"); Promise.all([promise1, promise2, promise3]) .then(([usersRes, postsRes, commentsRes]) => { // All three completed return Promise.all([ usersRes.json(), postsRes.json(), commentsRes.json() ]); }) .then(([users, posts, comments]) => { console.log({ users, posts, comments }); }) .catch((error) => { // If ANY promise rejects, catch is called console.error("One of the requests failed:", error); }); ``` **TypeScript typing:** ```typescript async function fetchAllData(): Promise<[User[], Post[], Comment[]]> { const results = await Promise.all([ fetchUsers(), // Promise fetchPosts(), // Promise fetchComments() // Promise ]); return results; // TypeScript infers the tuple type } ``` **Important:** `Promise.all()` fails fast. If any Promise rejects, the entire `Promise.all()` rejects immediately. ### Promise.allSettled(): All Results, Regardless of Outcome When you want all results, even if some fail: ```js const promises = [ fetch("/api/users"), fetch("/api/might-fail"), fetch("/api/posts") ]; Promise.allSettled(promises).then((results) => { results.forEach((result, index) => { if (result.status === "fulfilled") { console.log(`Promise ${index} succeeded:`, result.value); } else { console.log(`Promise ${index} failed:`, result.reason); } }); }); ``` Each result is an object with: - `status`: "fulfilled" or "rejected" - `value`: The resolved value (if fulfilled) - `reason`: The rejection reason (if rejected) **TypeScript typing:** ```typescript type SettledResult = | { status: "fulfilled"; value: T } | { status: "rejected"; reason: any }; const results: SettledResult[] = await Promise.allSettled(promises); ``` ### Promise.race(): First to Complete Resolves or rejects with the first Promise to settle: ```js const timeout = new Promise((_, reject) => { setTimeout(() => reject(new Error("Timeout!")), 5000); }); const fetchData = fetch("/api/data"); Promise.race([fetchData, timeout]) .then((response) => { console.log("Got response before timeout"); return response.json(); }) .catch((error) => { console.error("Failed:", error.message); // "Timeout!" if too slow }); ``` This is useful for implementing timeouts. ### Promise.any(): First to Succeed Resolves with the first fulfilled Promise. Only rejects if all Promises reject: ```js const mirrors = [ fetch("https://mirror1.example.com/data"), fetch("https://mirror2.example.com/data"), fetch("https://mirror3.example.com/data") ]; Promise.any(mirrors) .then((response) => { console.log("Got response from fastest mirror"); return response.json(); }) .catch((error) => { // AggregateError containing all rejection reasons console.error("All mirrors failed:", error.errors); }); ``` This is useful when you have multiple sources for the same data and want the first successful one. ### Composing Patterns: TypeScript Example Here's a practical example combining multiple patterns: ```typescript interface User { id: number; name: string; } interface Post { id: number; title: string; userId: number; } async function getUserWithPosts(userId: number): Promise<{ user: User; posts: Post[]; }> { // Fetch user first const userResponse = await fetch(`/api/users/${userId}`); if (!userResponse.ok) { throw new Error(`Failed to fetch user: ${userResponse.status}`); } const user: User = await userResponse.json(); // Then fetch their posts const postsResponse = await fetch(`/api/posts?userId=${userId}`); if (!postsResponse.ok) { throw new Error(`Failed to fetch posts: ${postsResponse.status}`); } const posts: Post[] = await postsResponse.json(); return { user, posts }; } // Usage getUserWithPosts(1) .then(({ user, posts }) => { console.log(`${user.name} has ${posts.length} posts`); }) .catch((error) => { console.error("Failed to load user data:", error); }); ``` --- ## Error Handling in Promises Proper error handling is crucial for robust async code. Promises provide a clean model for this, but there are subtleties to understand. ### .catch() Placement Matters Where you place `.catch()` in a chain determines what errors it catches: ```js // Catches errors from the fetch only fetch("/api/data") .catch((error) => { console.error("Fetch failed:", error); return { fallback: true }; }) .then((data) => { // This still runs even if fetch failed processData(data); // Could throw! }); // If processData throws, it's unhandled! // Better: catch at the end fetch("/api/data") .then((response) => response.json()) .then((data) => processData(data)) .catch((error) => { // Catches errors from fetch, json(), AND processData console.error("Something failed:", error); }); ``` **Rule of thumb:** Put `.catch()` at the end of your chain to catch all errors. ### Error Propagation Errors propagate down the chain until they're caught: ```js Promise.resolve() .then(() => { throw new Error("Error in step 1"); }) .then(() => { console.log("Step 2"); // Never runs }) .then(() => { console.log("Step 3"); // Never runs }) .catch((error) => { console.error("Caught:", error.message); // "Error in step 1" }) .then(() => { console.log("Step 4"); // Runs! Chain continues after catch }); ``` Output: ``` Caught: Error in step 1 Step 4 ``` After `.catch()` handles an error, the chain continues normally (unless `.catch()` itself throws). ### Rethrowing Errors Sometimes you want to log an error but still let it propagate: ```js fetch("/api/data") .then((response) => response.json()) .catch((error) => { console.error("Logging error:", error); throw error; // Rethrow to propagate }) .then((data) => { // Won't run if there was an error processData(data); }) .catch((error) => { // Handles rethrown error (or new errors from processData) showErrorUI(error); }); ``` ### Handling Specific Errors Check the error type or message to handle different errors differently: ```js class NetworkError extends Error { constructor(message) { super(message); this.name = "NetworkError"; } } class ValidationError extends Error { constructor(message) { super(message); this.name = "ValidationError"; } } fetchData() .then(validateData) .then(processData) .catch((error) => { if (error instanceof NetworkError) { showRetryButton(); } else if (error instanceof ValidationError) { showValidationMessage(error.message); } else { showGenericError(); } }); ``` ### Unhandled Rejections If a Promise rejects and there's no `.catch()`, you get an unhandled rejection: ```js // Bad: no error handling Promise.reject(new Error("Oops")); // In browsers: "Uncaught (in promise) Error: Oops" // In Node.js: UnhandledPromiseRejectionWarning (and process may exit in future versions) ``` You can catch these globally: ```js // Browser window.addEventListener("unhandledrejection", (event) => { console.error("Unhandled rejection:", event.reason); event.preventDefault(); // Prevents the default handling }); // Node.js process.on("unhandledRejection", (reason, promise) => { console.error("Unhandled rejection:", reason); }); ``` But don't rely on this. Always handle your errors properly. ### Best Practices for Promise Error Handling 1. **Always have a `.catch()` at the end of chains** 2. **Use specific error types** for different failure modes 3. **Don't swallow errors silently** (at least log them) 4. **Consider what happens after `.catch()`** (the chain continues) 5. **Use `.finally()` for cleanup** that should run regardless of outcome --- ## Async/Await: Promises Made Elegant Async/await is syntactic sugar over Promises. It makes asynchronous code look and behave like synchronous code, making it easier to read and reason about. ### The async Keyword Adding `async` before a function makes it return a Promise: ```js async function greet() { return "Hello"; } // Equivalent to: function greet() { return Promise.resolve("Hello"); } greet().then(console.log); // "Hello" ``` Even if you don't explicitly return a Promise, the return value is wrapped in one. ### The await Keyword `await` pauses the async function until a Promise settles: ```js async function fetchUser() { const response = await fetch("/api/user"); const user = await response.json(); return user; } // Equivalent Promise chain: function fetchUser() { return fetch("/api/user") .then((response) => response.json()); } ``` **Important:** `await` only pauses the async function, not the entire program. Other code continues to run. ```js async function demo() { console.log("Before await"); await delay(1000); console.log("After await"); } console.log("Start"); demo(); console.log("End"); ``` Output: ``` Start Before await End (1 second later) After await ``` ### Converting Promise Chains to Async/Await **Promise chain:** ```js function getUserPosts(userId) { return fetch(`/api/users/${userId}`) .then((response) => { if (!response.ok) throw new Error("User not found"); return response.json(); }) .then((user) => { return fetch(`/api/posts?userId=${user.id}`); }) .then((response) => response.json()) .then((posts) => { return { user, posts }; }); } ``` **With async/await:** ```js async function getUserPosts(userId) { const userResponse = await fetch(`/api/users/${userId}`); if (!userResponse.ok) throw new Error("User not found"); const user = await userResponse.json(); const postsResponse = await fetch(`/api/posts?userId=${user.id}`); const posts = await postsResponse.json(); return { user, posts }; } ``` The async/await version reads like synchronous code. Each step waits for the previous one to complete. ### TypeScript with Async Functions TypeScript infers return types for async functions: ```typescript // TypeScript infers Promise async function fetchUser(id: number) { const response = await fetch(`/api/users/${id}`); const user: User = await response.json(); return user; } // Explicit return type async function fetchUser(id: number): Promise { const response = await fetch(`/api/users/${id}`); return response.json(); } // With proper error handling async function fetchUser(id: number): Promise { try { const response = await fetch(`/api/users/${id}`); if (!response.ok) return null; return response.json(); } catch { return null; } } ``` ### When to Use Which Syntax **Use async/await when:** - You have sequential operations that depend on each other - You want cleaner, more readable code - You need to use try/catch for error handling - You're working with loops and async operations **Use Promise chains when:** - You're doing simple transformations - You want to use Promise composition methods (all, race, etc.) - You're writing one-liners - You need to attach multiple handlers to the same Promise **Mixed usage is fine:** ```js async function processAll(ids) { // Use Promise.all with async/await const results = await Promise.all( ids.map(async (id) => { const response = await fetch(`/api/items/${id}`); return response.json(); }) ); return results; } ``` ### Await Only Works with Promises `await` works with any "thenable" (object with a `.then()` method), but primarily with Promises: ```js async function demo() { const result1 = await 42; // Works, but pointless console.log(result1); // 42 const result2 = await Promise.resolve("hello"); console.log(result2); // "hello" const result3 = await fetch("/api/data"); console.log(result3); // Response object } ``` If you await a non-Promise value, it's wrapped in `Promise.resolve()`. --- ## Error Handling with Async/Await Async/await brings back familiar try/catch syntax for handling errors, but there are patterns and gotchas to know. ### Basic Try/Catch ```js async function fetchData() { try { const response = await fetch("/api/data"); if (!response.ok) { throw new Error(`HTTP error: ${response.status}`); } const data = await response.json(); return data; } catch (error) { console.error("Failed to fetch data:", error); throw error; // Re-throw if you want callers to handle it } } ``` The try/catch catches: - Network errors from `fetch` - Errors you explicitly throw - Errors from `response.json()` if response isn't valid JSON ### Catching Specific Errors ```typescript class ApiError extends Error { constructor(public statusCode: number, message: string) { super(message); this.name = "ApiError"; } } async function fetchUser(id: number): Promise { try { const response = await fetch(`/api/users/${id}`); if (!response.ok) { throw new ApiError(response.status, `Failed to fetch user ${id}`); } return await response.json(); } catch (error) { if (error instanceof ApiError) { if (error.statusCode === 404) { console.log("User not found, returning default"); return { id, name: "Unknown" }; } if (error.statusCode >= 500) { console.error("Server error, retrying..."); // Could implement retry logic here } } throw error; // Re-throw unexpected errors } } ``` ### The Wrapper Function Pattern For cleaner code, you can create a wrapper that handles errors consistently: ```typescript type Result = | { success: true; data: T } | { success: false; error: Error }; async function tryCatch( promise: Promise ): Promise> { try { const data = await promise; return { success: true, data }; } catch (error) { return { success: false, error: error instanceof Error ? error : new Error(String(error)) }; } } // Usage async function fetchUserSafely(id: number) { const result = await tryCatch(fetchUser(id)); if (!result.success) { console.error("Failed:", result.error.message); return null; } return result.data; } ``` This pattern avoids try/catch blocks and makes error handling explicit. ### Combining Async/Await with .catch() You can attach `.catch()` to awaited Promises: ```js async function fetchWithFallback() { // If fetch fails, use fallback const data = await fetch("/api/data") .then((r) => r.json()) .catch(() => ({ fallback: true })); return data; } ``` This is useful for inline fallbacks without full try/catch blocks. ### Error Handling with Promise.all When using `Promise.all` with async/await, one rejection fails everything: ```js async function fetchAllUsers(ids) { try { const users = await Promise.all( ids.map((id) => fetchUser(id)) ); return users; } catch (error) { // One fetch failed, we lose all results console.error("At least one fetch failed:", error); return []; } } ``` Use `Promise.allSettled` if you want partial results: ```js async function fetchAllUsersSafe(ids) { const results = await Promise.allSettled( ids.map((id) => fetchUser(id)) ); const users = results .filter((r) => r.status === "fulfilled") .map((r) => r.value); const errors = results .filter((r) => r.status === "rejected") .map((r) => r.reason); if (errors.length > 0) { console.warn(`${errors.length} fetches failed`); } return users; } ``` --- ## Advanced Patterns and Real-World Usage Let's explore patterns you'll encounter in production code. ### Sequential vs. Parallel Execution **Sequential (slow):** ```js async function fetchSequential(urls) { const results = []; for (const url of urls) { const response = await fetch(url); results.push(await response.json()); } return results; } // If each fetch takes 1s and you have 5 URLs = 5 seconds total ``` **Parallel (fast):** ```js async function fetchParallel(urls) { const promises = urls.map((url) => fetch(url).then((r) => r.json()) ); return Promise.all(promises); } // If each fetch takes 1s and you have 5 URLs = ~1 second total ``` **When to use which:** - Sequential: When each request depends on the previous result - Parallel: When requests are independent ### Retry Logic with Exponential Backoff Retry failed operations with increasing delays: ```typescript interface RetryOptions { maxAttempts: number; baseDelayMs: number; maxDelayMs: number; } async function withRetry( fn: () => Promise, options: RetryOptions = { maxAttempts: 3, baseDelayMs: 1000, maxDelayMs: 10000 } ): Promise { let lastError: Error; for (let attempt = 1; attempt <= options.maxAttempts; attempt++) { try { return await fn(); } catch (error) { lastError = error instanceof Error ? error : new Error(String(error)); if (attempt === options.maxAttempts) { break; } // Exponential backoff with jitter const delay = Math.min( options.baseDelayMs * Math.pow(2, attempt - 1) + Math.random() * 1000, options.maxDelayMs ); console.log(`Attempt ${attempt} failed, retrying in ${delay}ms...`); await new Promise((resolve) => setTimeout(resolve, delay)); } } throw lastError!; } // Usage const data = await withRetry( () => fetch("/api/flaky-endpoint").then((r) => r.json()), { maxAttempts: 5, baseDelayMs: 500, maxDelayMs: 5000 } ); ``` ### Timeout Wrapper Add a timeout to any Promise: ```typescript function withTimeout(promise: Promise, ms: number): Promise { const timeout = new Promise((_, reject) => { setTimeout(() => { reject(new Error(`Operation timed out after ${ms}ms`)); }, ms); }); return Promise.race([promise, timeout]); } // Usage async function fetchWithTimeout(url: string) { try { const response = await withTimeout(fetch(url), 5000); return await response.json(); } catch (error) { if (error.message.includes("timed out")) { console.error("Request took too long"); } throw error; } } ``` ### Cancellation with AbortController Modern way to cancel fetch requests: ```typescript async function fetchWithCancel(url: string, signal?: AbortSignal) { const response = await fetch(url, { signal }); return response.json(); } // Usage const controller = new AbortController(); // Start the fetch const promise = fetchWithCancel("/api/data", controller.signal); // Cancel after 2 seconds if not done setTimeout(() => controller.abort(), 2000); try { const data = await promise; console.log("Got data:", data); } catch (error) { if (error.name === "AbortError") { console.log("Request was cancelled"); } else { throw error; } } ``` Useful for: - User navigates away from a page - User clicks a cancel button - Implementing request timeouts - Cleaning up on component unmount in React ### Rate Limiting / Throttling Process items with controlled concurrency: ```typescript async function processWithLimit( items: T[], fn: (item: T) => Promise, concurrencyLimit: number ): Promise { const results: R[] = []; const executing: Promise[] = []; for (const item of items) { const promise = fn(item).then((result) => { results.push(result); }); executing.push(promise); if (executing.length >= concurrencyLimit) { await Promise.race(executing); // Remove completed promises executing.splice( 0, executing.length, ...executing.filter((p) => !isSettled(p)) ); } } await Promise.all(executing); return results; } // Simpler version using a semaphore pattern async function processWithLimitSimple( items: T[], fn: (item: T) => Promise, limit: number ): Promise { const results: R[] = new Array(items.length); let index = 0; async function worker() { while (index < items.length) { const i = index++; results[i] = await fn(items[i]); } } await Promise.all( Array(Math.min(limit, items.length)) .fill(null) .map(() => worker()) ); return results; } // Usage: Process 100 URLs, max 5 at a time const urls = Array.from({ length: 100 }, (_, i) => `/api/item/${i}`); const results = await processWithLimitSimple( urls, async (url) => { const res = await fetch(url); return res.json(); }, 5 ); ``` ### Async Iterators and for-await-of For processing streams of async data: ```typescript async function* fetchPages(baseUrl: string) { let page = 1; let hasMore = true; while (hasMore) { const response = await fetch(`${baseUrl}?page=${page}`); const data = await response.json(); yield data.items; hasMore = data.hasNextPage; page++; } } // Usage async function getAllItems() { const allItems = []; for await (const items of fetchPages("/api/items")) { allItems.push(...items); console.log(`Fetched ${allItems.length} items so far...`); } return allItems; } ``` This is powerful for: - Paginated APIs - Real-time data streams - Processing large datasets in chunks --- ## Common Pitfalls and Gotchas Even experienced developers make these mistakes. Learn them so you can avoid them. ### Forgetting to Await One of the most common bugs: ```js async function saveUser(user) { // Bug: forgot await const result = saveToDatabase(user); // Returns Promise, not result! console.log("Saved:", result); // Logs: "Saved: Promise { }" return result; } // Fix async function saveUser(user) { const result = await saveToDatabase(user); console.log("Saved:", result); return result; } ``` TypeScript helps catch this when the types don't match what you expect. ### Await in Loops: Sequential vs. Parallel **Problem: Unintentionally sequential** ```js async function processItems(items) { const results = []; // This is SEQUENTIAL - each await waits for the previous for (const item of items) { const result = await processItem(item); results.push(result); } return results; } ``` If you have 10 items and each takes 1 second, this takes 10 seconds. **Solution: Parallel when possible** ```js async function processItems(items) { // This is PARALLEL - all start at once const results = await Promise.all( items.map((item) => processItem(item)) ); return results; } ``` Same 10 items take ~1 second. **But sometimes sequential is correct:** ```js async function processInOrder(items) { // When each step depends on the previous let accumulator = 0; for (const item of items) { accumulator = await processWithPrevious(item, accumulator); } return accumulator; } ``` ### Mixing Callbacks and Promises Don't mix paradigms without wrapping: ```js // Bad: callback inside async function async function readFiles() { fs.readFile("file.txt", (err, data) => { // This callback doesn't participate in the async flow! console.log(data); }); console.log("Done"); // Runs before file is read } // Good: promisify the callback API import { promisify } from "util"; const readFile = promisify(fs.readFile); async function readFiles() { const data = await readFile("file.txt"); console.log(data); console.log("Done"); // Runs after file is read } // Or use fs/promises in Node.js import { readFile } from "fs/promises"; ``` ### The Async IIFE Pattern When you need top-level await in environments that don't support it: ```js // This doesn't work at module scope (in older environments) const data = await fetchData(); // SyntaxError // Use an async IIFE (async () => { const data = await fetchData(); console.log(data); })(); // Or a named function async function main() { const data = await fetchData(); console.log(data); } main(); ``` Modern Node.js (14+) and browsers support top-level await in ES modules. ### Memory Leaks with Unresolved Promises Promises that never settle can cause memory leaks: ```js // Bad: this Promise never resolves const neverResolves = new Promise(() => { // Executor does nothing }); // Any .then() callbacks are held in memory forever neverResolves.then((value) => { // This callback is never cleaned up }); ``` Always ensure Promises eventually settle. Use timeouts as a safety net. ### Forgetting to Return in .then() ```js // Bug: no return fetch("/api/user") .then((response) => { response.json(); // Forgot return! }) .then((data) => { console.log(data); // undefined! }); // Fix fetch("/api/user") .then((response) => { return response.json(); // Or use arrow without braces }) .then((data) => { console.log(data); // Actual data }); // Cleaner with arrows fetch("/api/user") .then((response) => response.json()) .then((data) => console.log(data)); ``` ### Creating Promises Unnecessarily ```js // Bad: unnecessary Promise wrapper async function fetchData() { return new Promise((resolve) => { resolve(fetch("/api/data").then((r) => r.json())); }); } // Good: just return the Promise async function fetchData() { const response = await fetch("/api/data"); return response.json(); } // Also bad: wrapping already-async operation async function getData() { return new Promise(async (resolve) => { const data = await fetchSomething(); resolve(data); }); } // Good: just await and return async function getData() { return await fetchSomething(); // Or even simpler: return fetchSomething(); } ``` ### Error in Promise Constructor Errors in the executor are caught automatically: ```js const promise = new Promise((resolve, reject) => { throw new Error("Oops"); // Automatically becomes rejection }); promise.catch((err) => console.log(err.message)); // "Oops" ``` But errors in async callbacks inside the executor are NOT: ```js const promise = new Promise((resolve, reject) => { setTimeout(() => { throw new Error("Oops"); // Uncaught! Not caught by Promise }, 100); }); // Fix: catch manually const promise = new Promise((resolve, reject) => { setTimeout(() => { try { throw new Error("Oops"); } catch (err) { reject(err); } }, 100); }); ``` --- ## Interview Questions and Practice These are common interview questions about Promises and async/await. ### Question 1: "What's the output?" ```js console.log("1"); setTimeout(() => console.log("2"), 0); Promise.resolve().then(() => console.log("3")); console.log("4"); ``` **Answer:** `1, 4, 3, 2` **Why:** Synchronous code runs first (1, 4). Then microtasks (Promise callback: 3). Then macrotasks (setTimeout: 2). ### Question 2: "What's the output?" ```js async function async1() { console.log("async1 start"); await async2(); console.log("async1 end"); } async function async2() { console.log("async2"); } console.log("script start"); async1(); console.log("script end"); ``` **Answer:** ``` script start async1 start async2 script end async1 end ``` **Why:** `await` pauses the async function. Everything after `await` goes to the microtask queue. ### Question 3: "Implement Promise.all" ```js function promiseAll(promises) { return new Promise((resolve, reject) => { if (!Array.isArray(promises)) { return reject(new TypeError("Argument must be an array")); } if (promises.length === 0) { return resolve([]); } const results = new Array(promises.length); let completedCount = 0; promises.forEach((promise, index) => { Promise.resolve(promise) .then((value) => { results[index] = value; completedCount++; if (completedCount === promises.length) { resolve(results); } }) .catch(reject); // First rejection rejects the whole thing }); }); } // Test promiseAll([ Promise.resolve(1), Promise.resolve(2), Promise.resolve(3) ]).then(console.log); // [1, 2, 3] ``` ### Question 4: "Implement a sleep function" ```js function sleep(ms) { return new Promise((resolve) => setTimeout(resolve, ms)); } // Usage async function demo() { console.log("Start"); await sleep(2000); console.log("2 seconds later"); } ``` ### Question 5: "Execute promises in sequence" ```js function executeSequentially(promiseFns) { return promiseFns.reduce( (chain, promiseFn) => chain.then(promiseFn), Promise.resolve() ); } // Usage executeSequentially([ () => fetch("/api/1").then((r) => r.json()), () => fetch("/api/2").then((r) => r.json()), () => fetch("/api/3").then((r) => r.json()) ]); ``` ### Question 6: "What's wrong with this code?" ```js async function getUser() { try { const user = await fetchUser(); } catch (error) { console.log("Error:", error); } return user; // Bug! } ``` **Answer:** `user` is block-scoped to the try block. It's not accessible in the return statement. **Fix:** ```js async function getUser() { try { const user = await fetchUser(); return user; } catch (error) { console.log("Error:", error); return null; // Or throw } } ``` ### Question 7: "What's the output?" ```js const promise = new Promise((resolve, reject) => { resolve("Success"); reject("Error"); // Ignored resolve("Another"); // Ignored }); promise .then((value) => console.log(value)) .catch((error) => console.log(error)); ``` **Answer:** `Success` **Why:** A Promise can only be settled once. After `resolve("Success")`, subsequent `resolve` and `reject` calls are ignored. ### Practice Exercises 1. **Implement Promise.race** from scratch 2. **Create a promisify function** that converts callback-style functions to Promise-based 3. **Implement a request queue** that processes requests with a maximum concurrency limit 4. **Build a retry mechanism** that retries failed Promises with exponential backoff 5. **Create a debounced async function** that only executes after input stops for a specified time ### Self-Assessment Checklist After studying this guide, you should be able to answer "yes" to all of these: - ✅ Can you explain the event loop and the difference between task queue and microtask queue? - ✅ Do you understand the three states of a Promise? - ✅ Can you create a Promise from scratch using the constructor? - ✅ Do you know what .then() returns and why? - ✅ Can you explain why Promise callbacks are always asynchronous? - ✅ Do you understand the difference between Promise.all, allSettled, race, and any? - ✅ Can you convert a callback-based function to use Promises? - ✅ Do you know when to use try/catch vs .catch()? - ✅ Can you identify whether a loop with await is sequential or parallel? - ✅ Do you know how to implement timeout and retry patterns? --- ## Summary and Key Takeaways Let's consolidate everything we've learned about asynchronous JavaScript. ### The Mental Model JavaScript is single-threaded but non-blocking. The event loop enables concurrency by: 1. Executing synchronous code on the call stack 2. Delegating async operations to Web APIs / runtime 3. Queuing completed callbacks (tasks and microtasks) 4. Processing queues when the stack is empty **Microtasks (Promises) always run before macrotasks (setTimeout).** ### The Evolution - **Callbacks**: The original pattern. Works but leads to callback hell and inversion of control. - **Promises**: Objects representing future values. Chainable, composable, better error handling. - **Async/await**: Syntactic sugar over Promises. Makes async code look synchronous. ### Core Concepts **Promises have three states:** - Pending: Not yet settled - Fulfilled: Resolved with a value - Rejected: Failed with a reason **Promise methods:** - `.then()`: Handle fulfillment (and optionally rejection) - `.catch()`: Handle rejection - `.finally()`: Run code regardless of outcome **Composition methods:** - `Promise.all()`: Wait for all, fail fast - `Promise.allSettled()`: Wait for all, collect all results - `Promise.race()`: First to settle wins - `Promise.any()`: First to fulfill wins ### When to Use What | Scenario | Recommendation | |----------|----------------| | Simple async operation | async/await | | Chaining transformations | .then() chains | | Parallel operations | Promise.all with async/await | | Need all results even if some fail | Promise.allSettled | | Racing operations (timeout) | Promise.race | | First successful result | Promise.any | | Wrapping callback APIs | new Promise() | ### Best Practices 1. **Always handle errors** with .catch() or try/catch 2. **Use async/await** for readability when possible 3. **Parallelize independent operations** with Promise.all 4. **Don't forget to await** (or return) Promises 5. **Avoid mixing callbacks and Promises** without wrapping 6. **Use TypeScript** for better Promise type safety 7. **Implement timeouts** for network operations 8. **Consider cancellation** for user-initiated async operations ### Common Mistakes to Avoid - Forgetting to await - Sequential awaits when parallel is possible - Not returning in .then() callbacks - Swallowing errors silently - Creating unnecessary Promise wrappers - Mixing paradigms without proper conversion ### Further Resources - [MDN: Promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) - [MDN: async function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) - [JavaScript.info: Promises](https://javascript.info/promise-basics) - [Jake Archibald: Tasks, microtasks, queues](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/) ### Final Thoughts Asynchronous programming is fundamental to JavaScript. Whether you're building web applications, APIs, or command-line tools, you'll work with Promises and async/await constantly. The key is understanding the underlying model: the event loop, the microtask queue, and how Promises work under the hood. With that foundation, the syntax becomes intuitive, and debugging async issues becomes manageable. Practice is essential. Implement the exercises. Trace through the execution order examples. Build real projects that involve API calls, user interactions, and complex async flows. Async JavaScript can feel magical when you don't understand it and frustrating when things don't work as expected. With the knowledge from this guide, it should feel neither. It should feel like a powerful, predictable tool that you can wield with confidence. --- *This concludes our deep dive into Promises and async/await. If you have questions or want to share your own async patterns, feel free to reach out. Happy coding!*

Promises and Async/Await in JavaScript: A Complete Deep Dive