Promises and async/await in JavaScript, Explained

A promise is an object that represents a value you do not have yet — the result of something that finishes later, like a network request. async/await is cleaner syntax over promises that lets you write asynchronous code that reads top to bottom, instead of nesting callbacks.

Asynchronous code is where many self-taught developers stall, because it breaks the comforting illusion that programs run strictly line by line. They mostly do — but when you ask the network for data, JavaScript does not freeze and wait. Understanding what it does instead is the whole game, and it is a guaranteed interview topic.

Why async exists at all

JavaScript runs on a single thread. If it stopped and waited every time it fetched data from a server (which can take seconds), the entire page would freeze — no clicks, no scrolling, nothing. So slow operations are handed off, and your code keeps running. When the result is ready, your callback is invited back in.

This is why an async result cannot just be “returned” like a normal value: at the moment your line of code runs, the value genuinely does not exist yet.

Callbacks: the original pattern (and its problem)

The first way to handle “do this when it’s ready” was the callback — a function you pass in to be called later.

getUser(1, (user) => {
  getPosts(user.id, (posts) => {
    getComments(posts[0].id, (comments) => {
      // ...the "pyramid of doom"
    });
  });
});

It works, but nesting dependent calls produces deeply indented “callback hell” that is hard to read and harder to error-handle. Promises were created to flatten this.

Promises: a value that arrives later

A promise is in one of three states: pending, fulfilled (it worked, here’s the value), or rejected (it failed, here’s the error). You react with .then() for success and .catch() for failure.

fetch("/api/users/1")
  .then((res) => res.json())
  .then((user) => console.log(user.name))
  .catch((err) => console.error("Failed:", err));

The chain reads as a sequence of steps, each receiving the previous step’s result. Crucially, returning a promise from inside .then() flattens it — no more pyramid.

async/await: promises that read like normal code

async/await is the modern syntax, and it is just promises underneath. Mark a function async, and inside it you can await any promise — the function pauses there until the promise settles, then continues with the value.

async function loadUser(id) {
  try {
    const res = await fetch(`/api/users/${id}`);
    if (!res.ok) throw new Error("Not found");
    const user = await res.json();
    return user;            // an async function always returns a promise
  } catch (err) {
    console.error("Failed:", err);
  }
}

Two things to internalise:

• await pauses only this function, not the whole program. The event loop keeps serving everything else.
• Every async function returns a promise. So to use the result elsewhere, you await it again (or .then() it). This surprises beginners who expect a plain value back.

Errors are handled with ordinary try/catch, which is the biggest ergonomic win over .catch() chains.

Running things in parallel with Promise.all

await in sequence means waiting in sequence. If three requests do not depend on each other, awaiting them one by one is wasteful:

// Slow: 3 round-trips back to back
const a = await getA();
const b = await getB();
const c = await getC();

// Fast: all three at once, then wait for the slowest
const [a, b, c] = await Promise.all([getA(), getB(), getC()]);

Promise.all runs them concurrently and resolves when all are done — or rejects the moment any one fails. If you want every result regardless of individual failures, use Promise.allSettled.

The event loop: what actually happens

Here is the model that ties it together, and the part interviews dig into.

JavaScript has a call stack (what’s running now), and the host (browser/Node) provides timers and network APIs. When an async task finishes, its callback is placed in a queue. The event loop does one job: when the call stack is empty, it takes the next callback from the queue and runs it.

There are two queues, and the order matters:

This is why a resolved promise’s .then runs before a setTimeout(…, 0) queued earlier:

console.log("1");
setTimeout(() => console.log("2"), 0);
Promise.resolve().then(() => console.log("3"));
console.log("4");
// Output: 1, 4, 3, 2

Synchronous code (1, 4) runs first; then the microtask (3) drains before the macrotask (2). If you can explain that output, you understand the event loop.

Common mistakes

• Forgetting that async functions return promises. const u = loadUser(1) gives you a promise, not a user. You need await.
• await inside a forEach. forEach ignores the returned promise, so it does not wait. Use a for...of loop, or Promise.all(items.map(...)).
• Sequential awaits for independent work. Reach for Promise.all.
• Swallowing errors. An unhandled rejected promise can fail silently. Always try/catch around await, or .catch() a chain.

Where this sits in the bigger picture

Async is Phase 4 of our JavaScript roadmap, and it leans on closures — every callback closes over its surroundings, so it helps to have closures solid first.

The event loop, microtasks, and Promise.all patterns are drawn out step by step in JavaScript in Three Months, the job-ready tier — and pushed further (cancellation, concurrency limits, async iterators) in JavaScript for Staff Engineers.

Get comfortable here and asynchronous JavaScript stops feeling like magic and starts feeling like a queue you can reason about.