Can you use await outside an async function?

In modern JavaScript (ES2022+) you can use top-level await in ES modules (files with type="module" or .mjs extension). In older environments or CommonJS, await is only valid inside an async function.

Which is better for debugging?

async/await produces significantly better stack traces. Promise chains often show internal Promise machinery in stack traces. async/await stack traces look like synchronous code — you see the line that awaited the failing operation. Most developers and linters prefer async/await for this reason.

When would you still prefer .then()/.catch() over async/await?

Some functional programming patterns — chaining transformations with .then(transform1).then(transform2) — read cleanly as a pipeline. Also, when you want to attach error handling without try/catch verbosity: fetchData().catch(handleError). In most other cases, async/await is preferred.

JavaScript async comparison

Promise vs async/await in JavaScript

async/await is syntactic sugar on top of Promises — they are the same mechanism expressed differently. Understanding both helps you read other people's code, debug effectively, and choose the right style for each situation.

TL;DR

Promise (.then/.catch) — explicit chaining. Each step returns a new Promise. Good for functional pipelines. Can get unwieldy with complex logic (callback hell's spiritual successor).
async/await — syntactic sugar over Promises. Reads like synchronous code. Better stack traces, cleaner error handling with try/catch. The modern default.
Use async/await by default. Drop down to raw Promise methods (Promise.all, Promise.race, Promise.allSettled) for parallel coordination, where they are cleaner than awaiting in a loop.

Side-by-side comparison

Aspect	Promise (.then/.catch)	async/await
Readability	Chaining can become deeply indented	Reads like synchronous code
Error handling	.catch() at end of chain	try/catch blocks (familiar syntax)
Debugging	Stack traces show Promise internals	Clean stack traces, pauses at await
Parallel execution	Promise.all / Promise.race (explicit)	await Promise.all([...]) — best of both
Sequential execution	.then().then() — can be awkward	await a; await b; — natural and clear
Compatibility	ES6 (2015)	ES2017 (Node.js 7.6+, all modern browsers)
Return value	Returns a Promise from .then()	async function always returns a Promise
Functional style	Better for pipeline transformations	Better for imperative multi-step logic

Code side-by-side

Fetch a user, then fetch their latest order:

Promise (.then/.catch)

function loadUserOrder(userId) {
  return fetch('/api/users/' + userId)
    .then(res => {
      if (!res.ok) throw new Error(res.status);
      return res.json();
    })
    .then(user => fetch('/api/orders?userId=' + user.id))
    .then(res => res.json())
    .then(orders => orders[0])
    .catch(err => {
      console.error('Failed:', err);
      throw err;
    });
}

async/await

async function loadUserOrder(userId) {
  try {
    const userRes = await fetch('/api/users/' + userId);
    if (!userRes.ok) throw new Error(userRes.status);
    const user = await userRes.json();

    const ordersRes = await fetch(
      '/api/orders?userId=' + user.id
    );
    const orders = await ordersRes.json();
    return orders[0];
  } catch (err) {
    console.error('Failed:', err);
    throw err;
  }
}

When to use Promise methods directly

Parallel requests. await Promise.all([fetchA(), fetchB()]) fires both requests simultaneously. Awaiting them sequentially would be slower.
Race conditions. Promise.race([fetch(...), timeout()]) resolves with whichever settles first — great for implementing request timeouts.
All-settled scenarios. Promise.allSettled() waits for all Promises and returns results including failures — useful when you want results from as many sources as possible even if some fail.
Simple one-liner pipelines. fetch(url).then(r => r.json()).then(handleData).catch(handleError) is concise for a simple linear flow.

When to use async/await

Multi-step sequential logic. Reading a file, parsing it, validating the result, and writing back — four awaits that read like four lines of synchronous code.
Complex error handling. try/catch/finally lets you handle errors, clean up resources, and re-throw in a familiar pattern.
Conditional logic. Using if/else or for loops inside async/await is natural. Inside .then() callbacks it quickly becomes nested and hard to read.
Debugging. Set a breakpoint on an await line; the debugger pauses exactly there. Debugging nested .then() callbacks is notoriously painful.

English phrases engineers use

Promise conversations

"Chain a .then() to transform the response."
"Always add a .catch() at the end of the chain."
"Use Promise.all to fire both requests in parallel."
"This returns a pending Promise — the value is not available yet."
"We hit Promise hell — too many nested .then() callbacks."

async/await conversations

"Await the fetch before trying to parse the JSON."
"Wrap it in a try/catch to handle network errors."
"Don't forget — async functions return a Promise, not the raw value."
"You accidentally awaited in a loop — use Promise.all instead."
"Top-level await is fine in ES modules."

Quick decision tree

Multi-step sequential async logic → async/await
Fire multiple requests in parallel → await Promise.all()
Simple one-liner data fetch → Either (Promise .then is fine)
Complex error handling with cleanup → async/await + try/finally
Race to first result (e.g., timeout) → Promise.race()
Loop over items asynchronously → async/await (for...of + await)
Need all results including failures → Promise.allSettled()

Common Mistakes and Trade-offs

A remarkably common mistake when transitioning from Promises to async/await – and vice versa – is treating them as fundamentally different syntax for the same underlying asynchronous mechanism. Developers often incorrectly assume that `async/await` magically simplifies error handling or concurrency compared to Promise chains, leading to overly complex attempts at rewriting existing code. The core difference isn't syntactic; it's a matter of readability and flow. Promises are inherently built around chaining, which can quickly become difficult to reason about, particularly with deeply nested operations. Async/await provides a more synchronous-looking structure, making the control flow much easier to follow – but only if you understand how it interacts with the event loop. Failing to grasp this fundamental shift leads to introducing unnecessary complexity and potential bugs.

At scale, Promise chains frequently exhibit unexpected performance bottlenecks related to garbage collection. When many Promises are created and discarded within a short period, particularly in high-throughput environments like microservices or serverless functions, the JavaScript engine can struggle to efficiently manage memory allocation and deallocation associated with those unconsumed promises. Async/await mitigates this significantly because it avoids the creation of numerous intermediate Promise objects. The execution model of async/await is more directly tied to the event loop's handling of tasks, reducing the overhead of managing a large number of potentially orphaned Promises. This difference becomes acutely apparent when dealing with thousands or tens of thousands of concurrent requests.

There's a persistent misconception that async/await always represents a superior solution simply due to its cleaner syntax. While it undeniably improves readability for many scenarios, this isn't universally true. In very simple asynchronous operations – like fetching a single small JSON object – the added complexity of `async` and `await` may actually introduce more overhead than a straightforward Promise chain. Furthermore, async/await doesn't inherently solve concurrency issues; you still need to manage tasks and ensure proper synchronization if multiple asynchronous operations are dependent on each other. The perceived simplicity can mask underlying performance considerations if not carefully evaluated.

Migrating from Promises to async/await isn't a simple replacement; it often requires refactoring the entire control flow, which can be a significant undertaking, especially in large codebases. More critically, a common approach – simply wrapping existing Promise chains with `async` and `await` – doesn't address potential issues like unhandled rejections or missed error propagation. A more robust strategy involves restructuring the code to leverage async/await's inherent exception handling capabilities, rather than relying on `.catch()` blocks chained onto Promises. Furthermore, it's increasingly common to see hybrid approaches where async/await is used for new development and Promise chains are preserved in legacy systems, requiring careful consideration of how these two paradigms interact during inter-service communication or data processing pipelines.

Frequently asked questions

Is async/await just syntactic sugar for Promises?

Yes, exactly. An async function always returns a Promise; await simply pauses execution of the async function until the Promise resolves or rejects. Under the hood the JavaScript engine converts async/await to Promise chains. The two approaches are functionally equivalent — async/await is just easier to read and write.

How do you handle errors with async/await?

Use try/catch blocks. An awaited rejection throws inside the async function, so the catch block catches it exactly like a synchronous error. You can also call .catch() on the returned Promise of the async function if you prefer to handle errors at the call site.

How do you run multiple Promises in parallel with async/await?

Use Promise.all(). Awaiting Promises one after another (await a; await b;) runs them sequentially — each waits for the previous to finish. Promise.all([a, b]) starts them simultaneously and waits for both. const [userResult, postsResult] = await Promise.all([fetchUser(), fetchPosts()]) is the idiomatic pattern.

Show more questions (3)