When we write JavaScript or TypeScript, most of our code runs from top to bottom, line by line. This is what we usually think of as synchronous code. One line runs, then the next, then the next.
But when we need to get information from a server, things are different. We cannot just freeze the whole application while we wait for that data to come back. If a website or app did that, most users would probably leave before anything loaded.
So JavaScript needed a way to let certain tasks happen in the background while the rest of the application kept running. That way, we can show loading states, keep the page interactive, and update the UI once the data finally returns.
This is where asynchronous JavaScript comes in. It gives us a way to start a task now and deal with the result later without blocking the rest of our code. Over time, JavaScript introduced different ways to handle this, starting with callbacks and XMLHttpRequest, then moving to promises, the Fetch API, and finally async/await.
In this post, I am going to walk through that progression and show how asynchronous JavaScript evolved into what we use today.
Callbacks and XMLHttpRequest
Before promises and async/await, the main way to deal with asynchronous code was with callback functions.
If you have not come across them before, a callback is just a function passed into another function as an argument. That function gets called later once the task is complete.
Back then, one of the main tools used to communicate with servers in the browser was XMLHttpRequest, usually shortened to XHR. Despite the name, it was not only used for XML. It could also be used to work with JSON, which is what we use most often today. Before fetch() became the normal choice, XHR was the standard way to make HTTP requests in the browser.
Here is a simple example:
function getData(callback) {
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function () {
if (xhr.readyState === 4) {
if (xhr.status >= 200 && xhr.status < 300) {
callback(null, xhr.responseText);
} else {
callback("HTTP error: " + xhr.status);
}
}
};
xhr.open("GET", "/api/data", true);
xhr.send();
}
function renderContent(data) {
var container = document.getElementById("content");
container.innerHTML = "<p>" + data + "</p>";
}
function showError(error) {
var container = document.getElementById("content");
container.innerHTML = "<p>" + error + "</p>";
}
getData(function (error, data) {
if (error) {
showError(error);
return;
}
renderContent(data);
});
Let’s break down what is happening here.
First, we create a function called getData that accepts a callback. Inside it, we create an XMLHttpRequest object, which handles the request to the server.
Then we use xhr.onreadystatechange, which runs every time the request changes state. We check for xhr.readyState === 4, which means the request has finished. Once it has, we check the HTTP status code. If it is in the 200 range, the request succeeded, so we pass the response into the callback. If it failed, we pass back an error instead.
After that, we call xhr.open() to configure the request and xhr.send() to send it.
At the bottom, we call getData() and pass in another function. That callback decides what to do next. If there is an error, we show it. If not, we render the returned data on the page.
This worked, and for simple requests it was fine. But the problem started when multiple asynchronous tasks depended on each other.
Imagine needing to fetch a user, then fetch their posts, then fetch the comments for one of those posts. Every step depends on the previous one, which means the callbacks start getting nested inside each other. That is what became known as callback hell.
Here is a simple example of that:
function getUser(userId, callback) {
setTimeout(function () {
console.log("Fetched user");
callback(null, { id: userId, name: "Alice" });
}, 500);
}
function getPosts(userId, callback) {
setTimeout(function () {
console.log("Fetched posts");
callback(null, [
{ id: 1, title: "First Post", userId: userId },
{ id: 2, title: "Second Post", userId: userId },
]);
}, 500);
}
function getComments(postId, callback) {
setTimeout(function () {
console.log("Fetched comments");
callback(null, [
{ id: 1, text: "Nice post", postId: postId },
{ id: 2, text: "Thanks for sharing", postId: postId },
]);
}, 500);
}
getUser(42, function (err, user) {
if (err) {
console.error("Error fetching user:", err);
} else {
getPosts(user.id, function (err, posts) {
if (err) {
console.error("Error fetching posts:", err);
} else {
getComments(posts[0].id, function (err, comments) {
if (err) {
console.error("Error fetching comments:", err);
} else {
console.log("User:", user);
console.log("Posts:", posts);
console.log("Comments for first post:", comments);
}
});
}
});
}
});
Even in this small example, the code is already getting deeper, more repetitive, and harder to scan. As the number of requests grows, debugging and maintaining it becomes more of a hassle.
Developers needed a cleaner way to deal with async code.
That is where promises came in.
Promises
Promises gave JavaScript a much cleaner way to handle asynchronous work.
A promise is an object that represents a value we do not have yet, but expect to receive later. That future result can either succeed or fail.
A simple way to think about it is lending a pen to someone. They promise they will give it back. You do not know exactly when that will happen, and there is always a chance they come back without it. But instead of standing there waiting, you go and do other things. Then, once the result comes back, you deal with it.
That is basically how promises work in JavaScript.
A promise can end in two main ways:
- resolved, meaning the operation succeeded
- rejected, meaning something went wrong
We usually handle those outcomes with .then() and .catch():
- .then() handles the resolved value
- .catch() handles errors or rejections Here is an example of wrapping XHR in a promise:
function apiGet(url) {
return new Promise(function (resolve, reject) {
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function () {
if (xhr.readyState === 4) {
if (xhr.status >= 200 && xhr.status < 300) {
var data = JSON.parse(xhr.responseText);
resolve(data);
} else {
reject(new Error("Request failed with status " + xhr.status));
}
}
};
xhr.open("GET", url, true);
xhr.send();
});
}
apiGet("/api/user/42")
.then(function (user) {
console.log("User loaded:", user);
})
.catch(function (err) {
console.error("Error:", err);
});
Here, instead of accepting a callback, apiGet() returns a promise. Inside that promise, we call resolve() when the request succeeds and reject() when it fails.
This means the code that calls apiGet() can decide how to handle the result. That is a big improvement because it separates the request logic from the result-handling logic.
It also gave us a cleaner way to chain async steps together.
function getUser(userId) {
return new Promise((resolve) => {
setTimeout(() => {
resolve({ id: userId, name: "Alice" });
}, 500);
});
}
function getPosts(userId) {
return new Promise((resolve) => {
setTimeout(() => {
resolve([
{ id: 1, title: "First Post", userId: userId },
{ id: 2, title: "Second Post", userId: userId },
]);
}, 500);
});
}
function getComments(postId) {
return new Promise((resolve) => {
setTimeout(() => {
resolve([
{ id: 1, text: "Nice post", postId: postId },
{ id: 2, text: "Thanks for sharing", postId: postId },
]);
}, 500);
});
}
getUser(42)
.then((user) => {
console.log("User:", user);
return getPosts(user.id);
})
.then((posts) => {
console.log("Posts:", posts);
return getComments(posts[0].id);
})
.then((comments) => {
console.log("Comments:", comments);
})
.catch((error) => {
console.error("Something went wrong:", error);
});
This is still asynchronous, but it is much flatter than the callback version. It reads in a more natural order and is easier to debug.
The Fetch API
As promises became more common, browsers introduced a newer and cleaner way to make HTTP requests called the Fetch API.
The Fetch API is built around promises, which means it works naturally with .then() and .catch(). It quickly became the more modern replacement for XHR and is now what most frontend developers use by default in the browser.
Here is a simple example:
fetch("https://api.example.com/data")
.then((response) => {
if (!response.ok) {
throw new Error(`HTTP error: ${response.status}`);
}
return response.json();
})
.then((data) => console.log(data))
.catch((error) => console.error(error));
Let’s break it down.
First, fetch() sends the request and returns a promise.
When that promise resolves, we get back a response object. That is not the final JSON yet, it is the full HTTP response, so the first thing we often do is check response.ok.
If the request failed, we throw an error so that .catch() can handle it.
If the request succeeded, we call response.json(). That also returns a promise, which is why we need another .then() after it. Once that promise resolves, we finally have access to the parsed data.
Compared to XHR, this is much shorter and easier to follow. We no longer need to manage readyState, create request objects manually, or put all our logic inside event handlers.
But even with fetch and promises, long chains of .then() could still become difficult to read in more complex applications.
That is where async/await made things even cleaner.
Async Await
async/await gave us a way to write asynchronous code that looks much closer to normal synchronous code.
It is important to note that async/await is still built on promises. It does not replace them underneath, it just gives us a nicer syntax to work with them.
There are two main parts:
- async marks a function as asynchronous
- await pauses that function until a promise settles
Here is a basic example using fetch():
async function getData() {
try {
const response = await fetch("https://api.example.com/data");
if (!response.ok) {
throw new Error(`HTTP error: ${response.status}`);
}
const data = await response.json();
console.log(data);
} catch (error) {
console.error(error);
}
}
getData();
Here’s what is happening.
First, we add the async keyword to the function. That tells JavaScript we want to use await inside it.
Then we use await with fetch(). Instead of chaining .then(), we store the resolved response in a variable.
After that, we check whether the request succeeded.
Then we use await again with response.json() because parsing the response body is also asynchronous.
Finally, we wrap everything in a try...catch block, which lets us handle errors in one place.
This is one of the reasons async/await became so popular. It is still asynchronous, but it reads more like normal top-to-bottom code.
Here is the earlier user-posts-comments example rewritten using async/await:
function getUser(userId) {
return new Promise((resolve) => {
setTimeout(() => {
resolve({ id: userId, name: "Alice" });
}, 500);
});
}
function getPosts(userId) {
return new Promise((resolve) => {
setTimeout(() => {
resolve([
{ id: 1, title: "First Post", userId: userId },
{ id: 2, title: "Second Post", userId: userId },
]);
}, 500);
});
}
function getComments(postId) {
return new Promise((resolve) => {
setTimeout(() => {
resolve([
{ id: 1, text: "Nice post", postId: postId },
{ id: 2, text: "Thanks for sharing", postId: postId },
]);
}, 500);
});
}
async function loadUserData() {
try {
const user = await getUser(42);
console.log("User:", user);
const posts = await getPosts(user.id);
console.log("Posts:", posts);
const comments = await getComments(posts[0].id);
console.log("Comments for first post:", comments);
} catch (error) {
console.error("Error loading data:", error);
}
}
loadUserData();
This version is much easier to read because the steps happen in a clear order:
- get the user
- get the posts
- get the comments
No deep nesting, no long promise chain, and much less repeated error handling.
One important thing to remember is that await only pauses the async function it is inside. It does not block the whole browser or freeze the rest of your application.
That is the key difference. It looks synchronous, but it still behaves asynchronously under the hood.
Conclusion
Asynchronous JavaScript has come a long way.
We started with callbacks and XMLHttpRequest, which worked but quickly became messy when multiple requests depended on each other. Then promises gave us a cleaner and more structured way to manage async code. After that, the Fetch API made browser requests easier to write, and finally, async/await made asynchronous code feel far more natural to read.
At the end of the day, all of these approaches are solving the same problem: letting JavaScript keep running while waiting for something else to finish.
If you are learning JavaScript today, async/await is probably what you will use most often. But understanding callbacks, promises, and fetch is still really useful, because it helps you understand what is happening underneath and why modern async code looks the way it does.
If you want to learn more about JavaScript, check out: