qwertywelch
← Back to Blog

JavaScript Async Patterns: A Journey Through Callbacks, Promises, and Beyond

Join me as we explore the evolution of asynchronous JavaScript, from callback hell to the elegance of async/await. We'll compare different approaches, discover common pitfalls, and share real-world patterns I've learned along the way.

David Kim
David KimSoftware Engineer & Open Source Contributor

JavaScript Async Patterns: A Journey Through Callbacks, Promises, and Beyond

Hey everyone! I've been deep in async JavaScript lately, and I wanted to share what I've learned. If you've ever stared at a screen wondering why your code executed in the wrong order, or found yourself lost in a maze of nested callbacks, this post is for you.

Asynchronous programming in JavaScript has come a long way. Let's trace that evolution together and see how each pattern builds on what came before.

Why Async Matters

Before we dive in, let's talk about why this even matters. JavaScript is single-threaded. That means it can only do one thing at a time. If we wrote everything synchronously, our apps would freeze every time they waited for a network request or read a file.

Async patterns let us say, "Hey, go do this thing, and let me know when you're done. In the meantime, I'll keep working on other stuff."

Simple concept, but the implementation has evolved significantly over the years. Let me show you what I mean.

The Callback Era

Callbacks are where it all started. A callback is just a function you pass to another function, to be called later when some operation completes.

function fetchUserData(userId, callback) {
  setTimeout(() => {
    // Simulating an API call
    const user = { id: userId, name: 'David', email: '[email protected]' };
    callback(null, user);
  }, 1000);
}

fetchUserData(123, (error, user) => {
  if (error) {
    console.error('Failed to fetch user:', error);
    return;
  }
  console.log('Got user:', user.name);
});

This works! For simple cases, callbacks are totally fine. The problem emerges when you need to chain multiple async operations.

The Pyramid of Doom

Here's where things get messy. Say we need to fetch a user, then their posts, then comments on those posts:

fetchUser(userId, (err, user) => {
  if (err) {
    handleError(err);
    return;
  }
  fetchPosts(user.id, (err, posts) => {
    if (err) {
      handleError(err);
      return;
    }
    fetchComments(posts[0].id, (err, comments) => {
      if (err) {
        handleError(err);
        return;
      }
      // Finally! We can do something with all this data
      renderPage(user, posts, comments);
    });
  });
});

See that triangle forming? That's callback hell. It's not just ugly; it's genuinely hard to follow, debug, and maintain. Error handling is repetitive. And good luck adding another step in the middle.

I spent more time than I'd like to admit writing code like this early in my career. The frustration is real.

Callback Patterns That Help

If you're stuck with callbacks (maybe you're working with an older codebase), there are ways to make life better:

Named functions instead of anonymous ones:

function handleUser(err, user) {
  if (err) return handleError(err);
  fetchPosts(user.id, handlePosts);
}

function handlePosts(err, posts) {
  if (err) return handleError(err);
  fetchComments(posts[0].id, handleComments);
}

function handleComments(err, comments) {
  if (err) return handleError(err);
  renderPage(user, posts, comments);
}

fetchUser(userId, handleUser);

This flattens the code but introduces its own problems. Where does user come from in handleComments? You'd need closures or global state, neither of which is ideal.

Enter Promises

Promises changed everything for me. A Promise represents a value that might not be available yet but will be resolved at some point (or rejected if something goes wrong).

function fetchUserData(userId) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const user = { id: userId, name: 'David', email: '[email protected]' };
      resolve(user);
      // Or if something went wrong: reject(new Error('User not found'));
    }, 1000);
  });
}

fetchUserData(123)
  .then(user => console.log('Got user:', user.name))
  .catch(error => console.error('Failed:', error));

But here's where it gets beautiful. Promises chain:

fetchUser(userId)
  .then(user => fetchPosts(user.id))
  .then(posts => fetchComments(posts[0].id))
  .then(comments => renderPage(comments))
  .catch(error => handleError(error));

Look at that! Flat, readable, and one catch handles errors from any step. I remember the first time I refactored callback code to promises. It felt like cleaning a messy room.

Promise States

A Promise is always in one of three states:

  • Pending: Initial state, operation in progress
  • Fulfilled: Operation completed successfully
  • Rejected: Operation failed

Once a Promise settles (fulfilled or rejected), it stays that way forever. You can attach handlers before or after it settles, and they'll work the same way. That consistency is really valuable.

Creating Promises

You'll often wrap callback-based APIs in Promises:

function readFilePromise(path) {
  return new Promise((resolve, reject) => {
    fs.readFile(path, 'utf8', (err, data) => {
      if (err) reject(err);
      else resolve(data);
    });
  });
}

Node.js even has util.promisify to do this automatically:

const { promisify } = require('util');
const readFile = promisify(fs.readFile);

Common Promise Pitfalls

I've made all of these mistakes. Learn from my pain:

Forgetting to return in .then():

// Wrong - breaks the chain
fetchUser(id)
  .then(user => {
    fetchPosts(user.id); // No return! Next .then gets undefined
  })
  .then(posts => console.log(posts)); // undefined!

// Right
fetchUser(id)
  .then(user => {
    return fetchPosts(user.id);
  })
  .then(posts => console.log(posts)); // Works!

Nesting Promises (defeating the purpose):

// Don't do this - you're recreating callback hell
fetchUser(id).then(user => {
  fetchPosts(user.id).then(posts => {
    fetchComments(posts[0].id).then(comments => {
      // Nested again!
    });
  });
});

// Do this instead
fetchUser(id)
  .then(user => fetchPosts(user.id))
  .then(posts => fetchComments(posts[0].id))
  .then(comments => { /* flat! */ });

Promise.all: Parallel Power

What if you need to fetch multiple things at once? Promise.all is your friend:

const userPromise = fetchUser(userId);
const settingsPromise = fetchSettings(userId);
const notificationsPromise = fetchNotifications(userId);

Promise.all([userPromise, settingsPromise, notificationsPromise])
  .then(([user, settings, notifications]) => {
    // All three completed! Order matches the input array.
    renderDashboard(user, settings, notifications);
  })
  .catch(error => {
    // If ANY promise rejects, we end up here
    handleError(error);
  });

This is way faster than fetching sequentially when the operations are independent. Instead of waiting 3 seconds (1 + 1 + 1), you wait 1 second (they run in parallel).

Important gotcha: Promise.all fails fast. If any promise rejects, the whole thing rejects immediately. The other promises keep running, but you won't get their results.

Promise.allSettled: When You Need Everything

Sometimes you want all results, even if some fail. That's what Promise.allSettled gives you:

const promises = urls.map(url => fetch(url));

Promise.allSettled(promises).then(results => {
  results.forEach((result, index) => {
    if (result.status === 'fulfilled') {
      console.log(`${urls[index]} succeeded:`, result.value);
    } else {
      console.log(`${urls[index]} failed:`, result.reason);
    }
  });
});

I use this a lot for batch operations where partial success is acceptable.

Promise.race: First One Wins

Promise.race resolves or rejects as soon as the first promise settles:

const timeout = new Promise((_, reject) => {
  setTimeout(() => reject(new Error('Timeout!')), 5000);
});

Promise.race([fetchData(), timeout])
  .then(data => console.log('Got data:', data))
  .catch(error => console.error('Failed or timed out:', error));

This pattern is great for implementing timeouts. If the fetch takes longer than 5 seconds, we get the timeout rejection.

Promise.any: First Success Wins

Promise.any is like race, but it waits for the first fulfilled promise, ignoring rejections:

const mirrors = [
  fetch('https://mirror1.example.com/data'),
  fetch('https://mirror2.example.com/data'),
  fetch('https://mirror3.example.com/data')
];

Promise.any(mirrors)
  .then(response => console.log('Got response from fastest mirror'))
  .catch(error => console.error('All mirrors failed'));

It only rejects if ALL promises reject.

Async/Await: The Game Changer

When async/await arrived, it felt like JavaScript finally got async right. It's built on Promises but reads like synchronous code:

async function loadUserDashboard(userId) {
  try {
    const user = await fetchUser(userId);
    const posts = await fetchPosts(user.id);
    const comments = await fetchComments(posts[0].id);
    renderPage(user, posts, comments);
  } catch (error) {
    handleError(error);
  }
}

That's it. No callbacks. No .then chains. Just code that reads top to bottom, exactly how you'd write synchronous code.

How It Works

An async function always returns a Promise. The await keyword pauses execution until the Promise settles. If it rejects, await throws the error, which is why we can use try/catch.

async function example() {
  return 42;
}

example().then(value => console.log(value)); // 42

Parallel with Async/Await

One thing that tripped me up: await pauses execution. If you await sequentially, you lose parallelism:

// Sequential - slow!
async function loadData() {
  const user = await fetchUser();      // Wait 1 second
  const posts = await fetchPosts();    // Then wait 1 more second
  const comments = await fetchComments(); // Then wait 1 more second
  // Total: 3 seconds
}

// Parallel - fast!
async function loadData() {
  const [user, posts, comments] = await Promise.all([
    fetchUser(),
    fetchPosts(),
    fetchComments()
  ]);
  // Total: 1 second (they run together)
}

Start all the promises first, then await them together. This is one of those things that seems obvious in retrospect but caught me off guard initially.

Error Handling Patterns

Try/catch works great, but it can get verbose if you're handling errors differently for each operation:

async function loadData() {
  let user, posts;

  try {
    user = await fetchUser();
  } catch (error) {
    user = getDefaultUser();
  }

  try {
    posts = await fetchPosts(user.id);
  } catch (error) {
    posts = [];
  }

  return { user, posts };
}

I've seen folks use a helper function to make this cleaner:

async function to(promise) {
  try {
    const result = await promise;
    return [null, result];
  } catch (error) {
    return [error, null];
  }
}

async function loadData() {
  const [userErr, user] = await to(fetchUser());
  if (userErr) return handleError(userErr);

  const [postsErr, posts] = await to(fetchPosts(user.id));
  if (postsErr) return handleError(postsErr);

  return { user, posts };
}

This Go-style error handling isn't for everyone, but it's an interesting pattern.

Real-World Patterns I Use All The Time

Let me share some patterns that come up constantly in my work:

Retry with Exponential Backoff

When a request fails, retry with increasing delays:

async function fetchWithRetry(url, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      return await fetch(url);
    } catch (error) {
      if (attempt === maxRetries - 1) throw error;

      const delay = Math.pow(2, attempt) * 1000; // 1s, 2s, 4s
      await new Promise(resolve => setTimeout(resolve, delay));
    }
  }
}

Batch Processing with Concurrency Limit

When processing many items, limit how many run at once:

async function processInBatches(items, batchSize, processor) {
  const results = [];

  for (let i = 0; i < items.length; i += batchSize) {
    const batch = items.slice(i, i + batchSize);
    const batchResults = await Promise.all(batch.map(processor));
    results.push(...batchResults);
  }

  return results;
}

// Process 100 items, 10 at a time
await processInBatches(items, 10, item => processItem(item));

Debounced Async Function

Useful for search inputs where you don't want to fire requests on every keystroke:

function debounceAsync(fn, delay) {
  let timeoutId;
  let pendingPromise;

  return function(...args) {
    clearTimeout(timeoutId);

    return new Promise((resolve, reject) => {
      timeoutId = setTimeout(async () => {
        try {
          const result = await fn.apply(this, args);
          resolve(result);
        } catch (error) {
          reject(error);
        }
      }, delay);
    });
  };
}

const debouncedSearch = debounceAsync(searchAPI, 300);

Wrapping Up

We've come a long way from callback hell. Each pattern built on the last:

  • Callbacks taught us async fundamentals
  • Promises gave us chainable, composable operations
  • Async/await gave us readable, synchronous-looking code

My advice? Get comfortable with all of them. You'll encounter callbacks in older code and libraries. Promises are still essential, especially Promise.all and its friends. And async/await is what you'll reach for most often.

The key insight that took me a while to internalize: these aren't competing approaches. They're layers. Async/await is syntax sugar over Promises. Promises are a pattern for managing callbacks. Understanding all three makes you better at each one.

Thanks for joining me on this journey through async JavaScript! If you're experimenting with these patterns, I'd love to hear what you're building. We're all learning together.

David Kim
Written byDavid KimSoftware Engineer & Open Source Contributor
Read more articles