Let’s talk about keeping your JavaScript applications fast and responsive. When your code has to wait for something—like data from a server, a timer, or reading a file—you can’t just freeze the whole app. That’s where asynchronous patterns come in. They are ways to handle these waiting operations without blocking everything else. I’ve found that mixing and matching these techniques is the key to building smooth software.

The most basic idea is the callback. You give a function to another function to run later, when a task is done. It’s simple to understand at first. You say, “Go get this data, and then run this function with the result.”

function makeNetworkRequest(url, whatToDoNext) {
  console.log(`Starting request to ${url}`);
  setTimeout(() => {
    console.log(`Got response from ${url}`);
    whatToDoNext(null, `Data from ${url}`);
  }, 1000);
}

makeNetworkRequest('https://api.example.com/users', (error, data) => {
  if (error) {
    console.error('Oops:', error);
  } else {
    console.log('Received:', data);
  }
});

The trouble starts when you have to do several things in a row. You end up with functions inside functions inside functions, moving further and further to the right. People call this “callback hell.” It gets hard to read and even harder to figure out where an error happened.

makeNetworkRequest('/api/user', (err, user) => {
  if (err) return console.error(err);
  makeNetworkRequest(`/api/posts/${user.id}`, (err, posts) => {
    if (err) return console.error(err);
    makeNetworkRequest(`/api/comments/${posts[0].id}`, (err, comments) => {
      if (err) return console.error(err);
      console.log('Finally got comments:', comments);
    });
  });
});

To fix this nesting problem, we got promises. A promise is an object that represents a future value. It starts off pending, then it can either be fulfilled with a value or rejected with a reason for failing. It gives you a cleaner way to chain operations together.

function makeRequestPromise(url) {
  return new Promise((resolve, reject) => {
    console.log(`Promise: Starting request to ${url}`);
    setTimeout(() => {
      console.log(`Promise: Got response from ${url}`);
      resolve(`Promise Data from ${url}`);
    }, 1000);
  });
}

makeRequestPromise('/api/user')
  .then(user => {
    console.log('Step 1 done:', user);
    return makeRequestPromise(`/api/posts/${user.id}`);
  })
  .then(posts => {
    console.log('Step 2 done:', posts);
    return makeRequestPromise(`/api/comments/${posts[0].id}`);
  })
  .then(comments => {
    console.log('All done! Comments:', comments);
  })
  .catch(error => {
    console.error('Something broke in the chain:', error);
  });

Notice how the .then() methods chain? Each one receives the result of the previous promise and returns a new one. A single .catch() at the end can handle any error that occurs in the entire chain. It’s much flatter and more organized.

You can also do multiple things at the same time. Promise.all is incredibly useful for this. It takes an array of promises and waits for all of them to finish. If any one fails, the whole thing fails immediately.

const userIds = [1, 2, 3, 4, 5];
const userFetchPromises = userIds.map(id => makeRequestPromise(`/api/users/${id}`));

Promise.all(userFetchPromises)
  .then(allUserData => {
    console.log('All users loaded!', allUserData);
  })
  .catch(error => {
    console.error('Failed to load one or more users:', error);
  });

Promises are great, but the syntax can still feel a bit detached. The async and await keywords let you write asynchronous code that looks almost like regular, synchronous code. You mark a function with async, which means it will always return a promise. Inside it, you use await to pause the function until a promise settles.

async function fetchUserDashboard(userId) {
  try {
    console.log('Fetching user...');
    const user = await makeRequestPromise(`/api/users/${userId}`);
    
    console.log('Fetching posts...');
    const posts = await makeRequestPromise(`/api/posts?userId=${userId}`);
    
    console.log('Fetching notifications...');
    const notifications = await makeRequestPromise(`/api/notifications/${userId}`);
    
    console.log('All data ready!');
    return { user, posts, notifications };
  } catch (error) {
    console.error('Could not build dashboard:', error);
    throw error; // Re-throw so the caller knows it failed
  }
}

// Using the async function
fetchUserDashboard(123)
  .then(dashboard => console.log(dashboard));

The try...catch block works perfectly with await, making error handling feel natural. To run things in parallel with async/await, you still lean on Promise.all.

async function fetchInParallel(userId) {
  const [user, posts, notifications] = await Promise.all([
    makeRequestPromise(`/api/users/${userId}`),
    makeRequestPromise(`/api/posts?userId=${userId}`),
    makeRequestPromise(`/api/notifications/${userId}`)
  ]);
  return { user, posts, notifications };
}

Sometimes, you’re not just waiting for one operation to finish. You’re dealing with things that happen multiple times, like user clicks, data arriving in chunks, or chat messages. This is where event emitters shine. An object can emit named events, and other parts of your code can listen for them. It’s a classic pattern in Node.js and browsers.

class SimpleEmitter {
  constructor() {
    this.eventListeners = {};
  }

  on(eventName, listenerFunction) {
    if (!this.eventListeners[eventName]) {
      this.eventListeners[eventName] = [];
    }
    this.eventListeners[eventName].push(listenerFunction);
  }

  emit(eventName, data) {
    const listeners = this.eventListeners[eventName];
    if (!listeners) return;
    listeners.forEach(listener => listener(data));
  }
}

// Using it
const chatRoom = new SimpleEmitter();

chatRoom.on('message', (msg) => {
  console.log(`New message from ${msg.user}: ${msg.text}`);
});

chatRoom.on('userJoined', (user) => {
  console.log(`${user} has joined the room.`);
});

// Simulating events
chatRoom.emit('userJoined', 'Alice');
chatRoom.emit('message', { user: 'Alice', text: 'Hello, everyone!' });

This pattern is fantastic for decoupling code. The chatRoom object doesn’t need to know who’s listening; it just announces that something happened. Many listeners can react independently.

Taking the event idea further, we get to observables and streams. Think of an observable as a lazy collection of data that arrives over time. You subscribe to it, and it can push multiple values to you (like events), and then eventually signal it’s done or that an error occurred. Libraries like RxJS turn this concept into a powerhouse for managing complex async flows.

Here’s a very basic, homemade observable to illustrate the concept:

function createObservable(subscribeFunction) {
  return {
    subscribe(observer) {
      const subscription = {
        isActive: true,
        unsubscribe() { this.isActive = false; }
      };
      subscribeFunction({
        next: (value) => {
          if (subscription.isActive && observer.next) observer.next(value);
        },
        error: (err) => {
          if (subscription.isActive && observer.error) observer.error(err);
        },
        complete: () => {
          if (subscription.isActive && observer.complete) observer.complete();
        }
      });
      return subscription;
    }
  };
}

// Creating an observable of mouse clicks
const clickObservable = createObservable((observer) => {
  const handler = (event) => observer.next({ x: event.clientX, y: event.clientY });
  document.addEventListener('click', handler);
  // Provide a way to clean up
  return () => document.removeEventListener('click', handler);
});

// Subscribing to it
const clickSubscription = clickObservable.subscribe({
  next: (coords) => console.log('Click at', coords),
  error: (err) => console.error('Observable error', err),
  complete: () => console.log('No more clicks will be tracked.')
});

// To stop listening after 10 seconds
setTimeout(() => {
  clickSubscription.unsubscribe();
  console.log('Unsubscribed from clicks.');
}, 10000);

Generators, marked by function*, are a different tool. They are functions you can pause and resume. They produce a sequence of values over time using the yield keyword. When combined with async patterns, they become “async generators,” which are perfect for things like reading a large file line-by-line or handling a paginated API.

// A simple generator
function* numberGenerator() {
  yield 1;
  yield 2;
  yield 3;
}

const gen = numberGenerator();
console.log(gen.next().value); // 1
console.log(gen.next().value); // 2
console.log(gen.next().value); // 3

// An ASYNC generator for paginated data
async function* fetchPaginatedData(endpoint) {
  let page = 1;
  let hasMore = true;

  while (hasMore) {
    // Simulate a network request for each page
    const response = await makeRequestPromise(`${endpoint}?page=${page}`);
    yield response.items; // Yield the batch of items

    hasMore = response.hasMore;
    page++;
  }
}

// Using the async generator
async function processAllProducts() {
  const productFetcher = fetchPaginatedData('/api/products');
  
  for await (const batch of productFetcher) {
    console.log(`Processing a batch of ${batch.length} products...`);
    // Do something with each batch
  }
  console.log('Finished processing all pages.');
}

The for await...of loop is the key here. It waits for the generator to yield the next value, processes it, and then loops again. It makes working with sequential, async data streams very readable.

Finally, when you have a task that’s so heavy it would freeze the browser or your Node.js server, you need Web Workers (in browsers) or Worker Threads (in Node.js). These let you run JavaScript in a separate, parallel thread. The main thread and the worker thread communicate by sending messages back and forth.

Here’s how you might set up a web worker for complex image processing:

main.js (Main Browser Thread)

// Create a new worker from a separate file
const imageWorker = new Worker('image-processor.js');

// Send data to the worker
const rawImageData = getImageDataFromCanvas();
imageWorker.postMessage({ command: 'process', data: rawImageData });

// Listen for messages FROM the worker
imageWorker.onmessage = function(event) {
  const { type, payload } = event.data;
  if (type === 'progress') {
    updateProgressBar(payload.percent);
  } else if (type === 'result') {
    displayProcessedImage(payload.image);
  }
};

// Handle errors from the worker
imageWorker.onerror = function(error) {
  console.error('Worker error:', error);
  showErrorMessage('Processing failed.');
};

image-processor.js (The Worker File)

// Listen for messages FROM the main thread
self.onmessage = function(event) {
  const { command, data } = event.data;
  
  if (command === 'process') {
    processImageData(data);
  }
};

function processImageData(rawData) {
  const totalPixels = rawData.length;
  const processedData = new Uint8ClampedArray(totalPixels);
  
  for (let i = 0; i < totalPixels; i += 4) {
    // Do some intense calculation on each pixel (R, G, B, A)
    processedData[i] = rawData[i] * 0.8;     // Red
    processedData[i+1] = rawData[i+1] * 1.1; // Green
    processedData[i+2] = rawData[i+2] * 0.9; // Blue
    processedData[i+3] = rawData[i+3];       // Alpha
    
    // Send progress update every 10,000 pixels
    if (i % 10000 === 0) {
      const percent = Math.round((i / totalPixels) * 100);
      self.postMessage({ type: 'progress', payload: { percent } });
    }
  }
  
  // Send the final result back
  self.postMessage({
    type: 'result',
    payload: { image: processedData }
  });
}

The main thread stays responsive because all the hard number crunching happens in the background worker. The worker can’t directly manipulate the DOM, but it can send the final result back for the main thread to use.

So, which pattern should you use? It depends. Start with async/await for most network or database operations; it’s the clearest. Use event emitters for things like UI components or real-time notifications. Look to observables (via RxJS) when you need powerful transformation of multiple event streams. Use generators for lazy sequences or pagination. And when performance is critical and you have heavy computations, move that work to a Web Worker.

The goal is never to use the most complicated pattern, but to use the simplest one that makes your code reliable and easy to understand. Mastering these tools lets you structure your application so that it waits patiently for the things it needs, without ever making the user wait.