Read asynchronous steps with async and await

One idea at a time

async and await provide another way to write promise-based code. An async function always returns a promise, even when it returns an ordinary number. Inside that function, await gives you a fulfilled result or throws the rejection reason. It makes a sequence easier to read without changing the underlying promise behavior.

Pausing the function is different from blocking the entire browser. Other work can continue while a promise is pending. However, a long synchronous calculation inside an async function still blocks while it executes. Adding async to a function is not a tool for making expensive CPU work run in parallel.

What to remember first

Walk through an example

async function showCount() {
  console.log("Start function");
  try {
    const count = await Promise.resolve(3);
    console.log(count);
  } catch {
    console.log("Could not load count");
  } finally {
    console.log("Cleanup");
  }
}
showCount();
console.log("Outside function continues");

showCount starts and logs its first message. At await, it suspends even though this promise is already fulfilled. The outer script logs Outside function continues. The function then resumes with 3 and runs cleanup. Compare the output order before assuming await behaves like a blocking sleep.

See it happen: try a small change

async function run() {
  console.log("Loading");
  try {
    const value = await Promise.resolve(3);
    console.log(value);
  } catch {
    console.log("Try again");
  } finally {
    console.log("Ready for another attempt");
  }
}
run();
console.log("Outer code continues");

Look a little closer

An async return value is wrapped in a promise. If you need the value from a call, await it in another async function or use then. Catch errors where your program can recover. A function that throws without a local catch returns a rejected promise to its caller, so the caller must handle that failure.

For UI code, plan all states before writing the request: idle, loading, success, and failure. Set loading before await, show success or failure afterward, and restore the disabled control in finally. This structure prevents an error from trapping the user behind a permanently disabled button.

Try it in your own project

Replace the previous chain with one async function, call it, and put an outside log after the call. Compare success and rejection. Keep await inside try so catch handles that rejection locally.

The interactive preview runs in its own isolated document. Its Output panel mirrors console.log messages; it is not a full DevTools console. Choosing another version or resetting starts a fresh example and does not edit your local files. Read any simulation label: storage and request demonstrations explain their offline substitutes, while the written local examples use the real browser APIs.

A common wrong turn

A try/catch does not catch a promise’s later rejection merely because that promise was created or returned inside try. Await it inside try to catch the rejection there; returning it without await leaves rejection handling to the caller. Put await inside try, or attach a catch to the promise. Also avoid awaiting independent operations one by one when they can safely start together; first decide whether there is a real dependency.

Go to the source

• MDN: Read asynchronous steps with async and await ↗

Examples are authored for Tuklas and checked with code and reference documentation. This is not a claim of independent human review. Suggest a correction.