Async JavaScript

If you have spent any real time writing JavaScript, you already know the language has a strange relationship with waiting. Browsers need to fetch data, read files, wait for timers, and respond to user clicks, all without freezing the page. JavaScript solves this with asynchronous programming, and over the years the language has offered three major tools to handle it: callbacks, promises, and async await. Understanding how these three approaches connect is one of the most valuable skills a JavaScript developer can build, because almost every modern web application, from a simple contact form to a complex single page app, depends on asynchronous code running smoothly behind the scenes.

What Does “Asynchronous” Actually Mean in JavaScript

JavaScript is single threaded, which means it can only do one thing at a time. If a task takes a long time, like fetching data from a server, the entire program would freeze while waiting unless there was a way to hand that task off and keep going. This is where asynchronous programming comes in. Instead of stopping everything, JavaScript hands the slow task to the browser or Node environment, keeps executing other code, and gets notified when the slow task is finished. This behavior is possible because of the event loop, a mechanism that constantly checks whether the call stack is empty and then pushes queued callback functions back into execution. Once you understand that JavaScript is not truly parallel but instead relies on this event driven queue system, callbacks, promises, and async await all start to make a lot more sense.

Callbacks: The Original Solution

Callbacks were the first widely used method for handling asynchronous operations in JavaScript. A callback is simply a function passed as an argument to another function, meant to be executed later once a task completes. For example, imagine you want to read data from a file in Node.js.

fs.readFile(‘data.txt’, ‘utf8’, function(err, data) {
if (err) {
console.error(‘Something went wrong’, err);
return;
}
console.log(data);
});

Here, the function passed as the third argument is the callback. It runs only after the file has been read, so your program does not sit idle waiting on disk access. Callbacks work fine for simple, one off asynchronous tasks. The trouble begins when you need to chain several asynchronous operations together. Suppose you need to fetch a user, then fetch their orders, then fetch details for each order. Each step depends on the previous one finishing, and with callbacks this quickly turns into deeply nested code that developers often call callback hell.

getUser(userId, function(user) {
getOrders(user.id, function(orders) {
getOrderDetails(orders[0].id, function(details) {
console.log(details);
});
});
});

Notice how the indentation grows with every additional step. This pattern is hard to read, harder to debug, and even harder to maintain when error handling is added at every level. Callback hell became one of the most common pain points in early JavaScript development, and it is the main reason the language eventually needed a better abstraction.

Promises: A Cleaner Way to Handle Async Code

Promises were introduced to solve the readability and error handling problems that callbacks created. A promise represents a value that may not be available yet but will be at some point in the future. It has three possible states: pending, fulfilled, or rejected. Instead of passing a callback directly into a function, you get back a promise object and chain handlers onto it using then and catch.

getUser(userId)
.then(function(user) {
return getOrders(user.id);
})
.then(function(orders) {
return getOrderDetails(orders[0].id);
})
.then(function(details) {
console.log(details);
})
.catch(function(error) {
console.error(‘Something failed’, error);
});

This structure is flatter and easier to follow than nested callbacks. Each then block returns a new promise, allowing you to chain operations in a readable sequence, and a single catch at the end can handle errors from any step in the chain. Promises also introduced useful static methods like Promise.all, which lets you run multiple asynchronous operations in parallel and wait for all of them to finish.

Promise.all([getUser(1), getUser(2), getUser(3)])
.then(function(users) {
console.log(users);
})
.catch(function(error) {
console.error(‘One of the requests failed’, error);
});

This is incredibly useful when you need several independent pieces of data and do not want to wait for them one after another. There is also Promise.race, which resolves or rejects as soon as the first promise in the array settles, often used for timeout patterns where you want to cancel a request if it takes too long.

Async and Await: Writing Asynchronous Code That Reads Like Synchronous Code

Even with promises, chaining many then calls together can still get messy, especially when you need conditional logic or loops mixed into asynchronous flows. Async and await, introduced in ES2017, built on top of promises to give developers a syntax that reads almost like regular synchronous code. Any function marked with the async keyword automatically returns a promise, and inside that function you can use await to pause execution until a promise resolves, without blocking the rest of the application.

async function getOrderDetailsForUser(userId) {
try {
const user = await getUser(userId);
const orders = await getOrders(user.id);
const details = await getOrderDetails(orders[0].id);
console.log(details);
} catch (error) {
console.error(‘Something failed’, error);
}
}

Compare this to the promise chain from earlier. The logic is identical, but the code reads top to bottom in a natural, linear way. Error handling also becomes simpler because you can wrap the entire sequence in a single try catch block instead of adding a catch after every chain. This readability advantage is the main reason async await has become the preferred approach for most modern JavaScript codebases, especially in frameworks like React, Vue, and Node based backend services.

Running Async Operations in Parallel with Async Await

One common mistake developers make when switching to async await is accidentally making independent operations run sequentially when they could run in parallel. If you await each call one after another, even when they do not depend on each other, you waste time.

async function loadDashboard(userId) {
const user = await getUser(userId);
const settings = await getSettings(userId);
const notifications = await getNotifications(userId);
return { user, settings, notifications };
}

In this example, settings and notifications do not depend on each other or on the user object, yet the code waits for each one before starting the next. A better approach combines async await with Promise.all to start all three requests at the same time.

async function loadDashboard(userId) {
const [user, settings, notifications] = await Promise.all([
getUser(userId),
getSettings(userId),
getNotifications(userId)
]);
return { user, settings, notifications };
}

This small change can meaningfully improve performance, especially in applications that make several API calls on page load.

Error Handling Across All Three Approaches

Error handling is where the differences between callbacks, promises, and async await become most obvious. With callbacks, you typically pass an error as the first argument to the callback function and manually check for it at every level, which becomes repetitive and easy to forget. With promises, errors propagate down the chain automatically until they hit a catch block, which centralizes error handling but can sometimes make it unclear exactly where something failed. With async await, try catch blocks bring familiar synchronous style error handling to asynchronous code, making it easier to reason about what happens when something goes wrong. Regardless of which pattern your codebase uses, the golden rule remains the same: never leave a promise unhandled and never assume an asynchronous operation will always succeed.

Choosing the Right Approach for Your Project

You might wonder which of these three patterns you should actually use in 2026. The honest answer is that callbacks are still common in older libraries and certain Node.js core APIs, so understanding them is essential even if you rarely write new code that way. Promises remain the foundation that async await is built on, and you will still see plain promise chains in many codebases, particularly in libraries that expose a promise based API without async functions. Async await is generally the best choice for new code because it is easier to read, easier to debug, and easier for teams to maintain over time. Many experienced developers recommend defaulting to async await for application logic while still understanding promises well enough to use Promise.all, Promise.race, and Promise.allSettled when you need more control over multiple concurrent operations.

Practical Tips for Writing Better Async JavaScript

A few habits consistently separate solid asynchronous code from fragile code. Always handle errors explicitly rather than assuming the happy path will always occur, since network requests and file operations fail more often than beginners expect. Avoid mixing async await with raw then chains in the same function, since combining the two styles often creates confusion rather than clarity. Use Promise.all when operations are independent to avoid unnecessary waiting, and reach for Promise.allSettled when you want results from every operation even if some of them fail. Keep async functions focused on a single responsibility, since long async functions with many awaited steps become difficult to test and debug. Finally, always remember that an async function returns a promise, so if you call an async function without awaiting it or handling its returned promise, unexpected bugs and unhandled rejection warnings can quietly creep into your application.

Wrapping Up

Callbacks, promises, and async await are not competing technologies as much as they are three stages in the evolution of the same underlying idea, handling operations that take time without freezing the rest of your program. Callbacks got JavaScript started with asynchronous programming but introduced messy, hard to maintain nested code. Promises cleaned that up with a more structured, chainable pattern and built in error propagation. Async await took that same promise based foundation and wrapped it in syntax that feels natural and readable, which is why it has become the standard approach in modern JavaScript development. Once you understand how these three techniques relate to one another, working with asynchronous code stops feeling confusing and starts feeling like one of the most powerful tools JavaScript gives you.