JavaScript callbacks, Promises, and async/await

Synchronous statements complete one after another. A long synchronous operation blocks JavaScript from continuing:

console.log('first');
console.log('second');

Asynchronous APIs let JavaScript start an operation and continue doing other work while the host environment waits. The host might be a browser or Node.js:

console.log('first');

setTimeout(() => {
  console.log('timer finished');
}, 0);

console.log('second');

The output is first, second, then timer finished. A delay of zero does not run the callback immediately. It schedules the callback to run after the current synchronous work has finished.

Asynchronous code and parallel code are related but different ideas. Asynchrony means the caller does not have to wait in place for completion. Parallelism means multiple pieces of work execute at the same instant. A browser can perform network work outside the JavaScript call stack, but JavaScript callbacks still run according to the runtime's event-loop rules.

console.log('A');
setTimeout(() => console.log('B'), 0);
console.log('C');

A callback is a function passed to other code for that code to invoke. A callback is not necessarily asynchronous: map invokes its callback while it processes an array, whereas timers and event listeners invoke callbacks after a later event:

const button = document.querySelector('button');

button.addEventListener('click', () => {
  console.log('The button was clicked');
});

Many Node.js APIs offer an error-first callback interface. The first callback argument contains an error when the operation fails; otherwise it is null, and later arguments contain the result:

import { readFile } from 'node:fs';

readFile('settings.json', 'utf8', (error, text) => {
  if (error) {
    console.error('Could not read settings:', error);
    return;
  }

  console.log(JSON.parse(text));
});

Callbacks are not obsolete. Event listeners, array methods, and many framework APIs still use them because a function is a natural way to provide behavior. Problems appear when several dependent asynchronous operations are represented by nested callbacks:

getUser(userId, (userError, user) => {
  if (userError) {
    handleError(userError);
    return;
  }

  getOrders(user.id, (ordersError, orders) => {
    if (ordersError) {
      handleError(ordersError);
      return;
    }

    getReceipt(orders[0].id, (receiptError, receipt) => {
      if (receiptError) {
        handleError(receiptError);
        return;
      }

      displayReceipt(receipt);
    });
  });
});

This shape is often called callback hell. Nesting is only part of the problem. Error handling is repeated, the success path drifts to the right, and the API must define rules such as whether a callback can run more than once.

A Promise is an object representing the eventual completion or failure of an asynchronous operation. A Promise begins as pending and later becomes fulfilled with a value or rejected with a reason. Once settled, its state cannot change again.

The built-in fetch API returns a Promise:

const request = fetch('/api/profile');

request
  .then((response) => {
    if (!response.ok) {
      throw new Error(`Request failed with ${response.status}`);
    }

    return response.json();
  })
  .then((profile) => {
    console.log(profile.name);
  })
  .catch((error) => {
    console.error('Could not load profile:', error);
  });

then registers a callback for fulfillment and returns a new Promise. That returned Promise is what makes a chain possible. Each step receives the previous step's result.

Returning asynchronous work from each handler is essential:

getUser(userId)
  .then((user) => getOrders(user.id))
  .then((orders) => getReceipt(orders[0].id))
  .then((receipt) => displayReceipt(receipt))
  .catch(handleError);

If a handler returns a Promise, the next then waits for it. If a handler returns an ordinary value, that value goes to the next step. If it throws or returns a rejected Promise, control moves to the nearest rejection handler.

Forgetting return breaks that relationship:

getUser(userId)
  .then((user) => {
    getOrders(user.id); // Not returned
  })
  .then((orders) => {
    console.log(orders); // undefined
  })
  .catch(handleError);

The second handler does not wait for getOrders, and a later rejection from that detached operation will not reach this chain's catch. Return getOrders(user.id) to connect it to the chain.

getUser(userId)
  .then((user) => getOrders(user.id))
  .then((orders) => displayOrders(orders))
  .catch(handleError);

Declaring a function with async makes it return a Promise. Returning an ordinary value fulfills that Promise, while throwing rejects it:

async function getGreeting(name) {
  if (!name) {
    throw new Error('A name is required');
  }

  return `Hello, ${name}`;
}

getGreeting('Maya').then(console.log); // "Hello, Maya"

Inside an async function, await waits for a Promise to settle. It gives back the fulfillment value or throws the rejection reason, which allows try/catch to handle rejected Promises:

async function showFirstReceipt(userId) {
  try {
    const user = await getUser(userId);
    const orders = await getOrders(user.id);
    const receipt = await getReceipt(orders[0].id);

    displayReceipt(receipt);
  } catch (error) {
    handleError(error);
  }
}

This code has the same dependency order as the earlier Promise chain. It is often easier to follow because values can be named and ordinary control-flow tools such as try/catch, if, and loops work naturally.

The phrase "await pauses execution" needs an important boundary: it suspends the current async function, not the JavaScript runtime. Other scripts, event handlers, and async operations can continue. When the awaited Promise settles, the function's continuation is scheduled to run.

async function fail() {
  throw new Error('No data');
}

const result = fail();

Use sequential awaits when each operation depends on the previous result:

const user = await getUser(userId);
const orders = await getOrders(user.id);

Do not accidentally serialize independent operations. This example waits for the profile before it even starts the notifications request:

const profile = await getProfile();
const notifications = await getNotifications();

Start independent operations together and await their combined result:

const [profile, notifications] = await Promise.all([getProfile(), getNotifications()]);

Promise.all fulfills when every input fulfills. It rejects as soon as one input rejects, although the other underlying operations are not automatically cancelled. Use Promise.allSettled when every outcome is needed even if some operations fail:

const results = await Promise.allSettled([updateSearchIndex(), sendConfirmationEmail()]);

The right choice depends on whether one failure makes the combined result unusable.

fetch rejects for failures that prevent an HTTP response, such as certain network errors or cancellation. It does not reject merely because the server returned 404 or 500. Check response.ok yourself:

async function loadProduct(productId) {
  const response = await fetch(`/api/products/${productId}`);

  if (!response.ok) {
    throw new Error(`Product request failed with ${response.status}`);
  }

  return response.json();
}

The caller can decide how to report or recover from that failure:

try {
  const product = await loadProduct('keyboard');
  renderProduct(product);
} catch (error) {
  renderError('The product could not be loaded');
  console.error(error);
}

Avoid catching an error only to hide it. Handle it when the code can recover, add useful context, translate it into a user-facing state, or clean up resources. Otherwise, let the rejection reach a caller that can make that decision.

Use a callback when the API is inherently event-based or explicitly expects a function, such as an event listener, array method, or one-shot callback API that does not need composition.

Use direct Promise methods when they express the operation clearly, when constructing a reusable chain, or when working outside an async function. A short transformation can be more concise with then:

const namesPromise = fetch('/api/users')
  .then(checkResponse)
  .then((response) => response.json())
  .then((users) => users.map((user) => user.name));

Use async/await for most modern sequences with several steps, branches, loops, or try/catch. It improves the shape of Promise-based code but does not make the work synchronous and does not remove the need to reason about dependencies, concurrency, and failures.

The progression from callbacks to Promises to async/await is therefore a progression in composition. Callbacks provide behavior for another API to invoke. Promises standardize an operation's eventual result. async/await lets Promise-based dependencies read from top to bottom. Understanding all three makes modern JavaScript easier to use and older JavaScript easier to maintain.

The chapter activities above test each asynchronous pattern where it is introduced. Use this final page to compare the styles and revisit any chapter whose activity exposed a gap.