Asynchronous JavaScript: Promises and async/await

Asynchronous JavaScript handles work whose result arrives later, including network requests, timers, user events, and some file operations. The program should remain responsive while it waits. Promises represent the future completion or failure of an operation; async and await provide clearer syntax for consuming those promises.

Begin with the synchronous model

Ordinary statements run in order. A calculation finishes before the next statement uses its result. A network request is different because its completion time is unknown. Freezing the page until it finishes would block input and rendering. JavaScript starts the external work, continues with eligible tasks, and schedules handling when the result becomes available.

Asynchronous does not automatically mean that your JavaScript runs on another CPU thread. It describes coordination over time. CPU-heavy code can still block the main thread and may require a worker or a different architecture.

A promise has a lifecycle

A promise begins pending. It later becomes fulfilled with a value or rejected with a reason. Once settled, it cannot change state. Attach .then() to transform a fulfilled value, .catch() to handle rejection, and .finally() for cleanup that applies to both outcomes.

fetch('/api/courses')
  .then(response => {
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    return response.json();
  })
  .then(courses => renderCourses(courses))
  .catch(error => showError(error.message))
  .finally(() => hideLoading());

The explicit status check matters: Fetch normally resolves when an HTTP response arrives, even if the status is 404 or 500. Network failure and an application error are different conditions.

Promise chains pass results forward

Each .then() returns a new promise. A handler can return a value, return another promise, or throw an error. Returning another promise makes the chain wait for it. Forgetting that return is a common bug because the outer chain can finish before the inner operation.

Functions that start asynchronous work should usually return their promise. The caller can then await it, compose it with other work, test its outcome, or decide where to handle errors.

async/await uses the same promise system

An async function always returns a promise. Inside it, await pauses that function until the awaited promise settles; it does not freeze the entire browser. Rejection behaves like a thrown error, so try, catch, and finally provide familiar control flow.

async function loadCourses() {
  try {
    showLoading();
    const response = await fetch('/api/courses');
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    const courses = await response.json();
    renderCourses(courses);
  } catch (error) {
    showError(error.message);
  } finally {
    hideLoading();
  }
}

This is not a separate alternative to promises. It is syntax built on them. Learn promise state and chaining so that stack traces, library APIs, and concurrency helpers remain understandable.

Sequential versus concurrent awaits

Use sequential awaits when one step needs the previous result—for example, loading a user before requesting that user’s orders. Independent requests can begin together. Promise.all() waits for all and rejects when one rejects, which fits work where every result is required. Promise.allSettled() reports every outcome and suits cases where partial results remain useful.

Do not add concurrency blindly. Consider server rate limits, resource use, ordering, and what the interface should do after partial failure. The fastest-looking code is not necessarily the clearest or safest.

Event-loop intuition

Current JavaScript runs on a call stack. Runtime facilities manage timers and I/O, then queue eligible callbacks. Promise reactions run as microtasks after the current stack completes. Therefore a .then() callback does not interrupt the synchronous code already running.

console.log('A');
Promise.resolve().then(() => console.log('B'));
console.log('C');

The output is A, C, B. Predicting examples like this is more useful than memorising a vague phrase such as “JavaScript runs everything at once.”

Error boundaries and cleanup

Catch an error where you can recover, add useful context, or present it appropriately. Avoid empty catches, because they convert visible failures into hidden wrong behaviour. Lower-level functions can throw meaningful errors; interface code can decide what users see. Log enough for diagnosis without exposing secrets or private server details.

Cancellation also matters. A user may navigate away or issue a newer search while an old request remains active. Fetch can use AbortController. Even when cancellation is unavailable, track which request is current so that a stale response does not overwrite newer state.

Common mistakes

• Forgetting await: code treats a promise as the final data.
• Awaiting inside forEach: the surrounding code does not wait for callback promises; use for...of for sequence or map items to promises.
• Serialising independent requests: unnecessary waiting accumulates.
• Handling only success: real interfaces also need loading, empty, failure, and retry states.
• Mixing styles carelessly: nested chains inside async functions can obscure which layer owns errors.
• Ignoring stale results: older responses can replace newer user choices.

A focused practice project

Build a search interface against a safe practice API. Display idle, loading, success, empty, and error states. Reject an invalid query before sending it, disable accidental duplicate submissions, cancel the previous request when a new search begins, and test slow responses with browser developer tools.

Next, fetch two independent resources concurrently and explain why partial failure should or should not be allowed. Write the same operation once as a promise chain and once with async/await. The goal is not to prefer shorter syntax; it is to explain timing, value flow, and error flow.

Continue learning

Use the MDN JavaScript Guide and Promise reference for language behaviour. For guided practice across browser and server JavaScript, review SKLI’s full stack development course curriculum and compare it with your current gaps. A course supports practice; it does not replace debugging your own asynchronous code.

Frequently asked questions

Does await block JavaScript?

It pauses the surrounding async function. Other eligible work can continue while the promise is pending.

Should I always use async/await?

No. It is often clear for sequential flow, while promise combinators express concurrent work well. Consistency and explicit error handling matter more than one style.

When should beginners study the event loop?

Learn basic callback and microtask ordering after you understand promise state. Deeper runtime details can follow when a real debugging problem requires them.