Sequential vs parallel

Async JavaScript is not just about can this wait? It is also about when should I start the work? Sequential code waits in a line. Parallel code starts independent work together and waits for the group. A concurrency limit starts a few at a time.

A precise one-line definition: sequential async work starts the next operation after the previous one settles; parallel async work starts independent operations before waiting for all of them; limited concurrency runs a fixed number at once.

const requests = [1200, 600, 900, 300];

// Sequential: next request starts after the previous one finishes.
for (const ms of requests) {
  await fakeRequest(ms);
}

// Parallel: start every request first, then wait for all of them.
await Promise.all(requests.map((ms) => fakeRequest(ms)));

// Limited: at most two workers pull work from the list.
await mapWithLimit(requests, 2, fakeRequest);

await inside for...of is sequential by design. That is perfect when each step needs the previous result, when order matters, or when an API asks you not to send too many requests. It is slow by accident when every item is independent.

The trap is forEach. It calls your async callback, but it ignores the promise returned by that callback. The outer function does not wait for those promises. Switch the setting below and watch the log order change.

1const items = ["A", "B", "C"];Run2items.forEach(async (item) => {3  await save(item);4  console.log("saved " + item);5});6console.log("done");

array.map(async ...) returns an array of promises. That array is useful only if something waits for it. The common shape is await Promise.all(promises): start every independent operation, then pause until the group fulfills.

1const promises = ids.map(async (id) => {2  return getProfile(id);3});4 5// promises is an array. This is the promise for the whole group.6const profiles = await Promise.all(promises);

Promise.all fails fast: if one promise rejects, the group rejects as soon as that rejection is observed. It does not cancel other operations that already started. The upcoming Cancellation with AbortController lesson teaches cancellation. When you want every outcome, including failures, use Promise.allSettled and inspect the status objects.

await getA(); await getB(); starts B after A finishes. If A and B are independent, create both promises first. The phrase to remember is: creating a promise starts the work; await decides when you stop and wait.

async function sequential() {
  const a = await getA();
  const b = await getB();
  return [a, b];
}

async function startEarly() {
  const aPromise = getA();
  const bPromise = getB();
  const a = await aPromise;
  const b = await bPromise;
  return [a, b];
}

async function safest() {
  return Promise.all([getA(), getB()]);
}

There is a professional gotcha. In the manual const bPromise = getB(); await aPromise; await bPromise; shape, bPromise may reject while you are still awaiting aPromise. Some browsers may report that momentarily as an unhandled rejection. Promise.all wires the group together immediately, so it is usually the safer expression for independent work.

Starting everything at once is not always kind. Browsers often limit simultaneous connections per server, historically around six for HTTP/1.1, while HTTP/2 can multiplex requests differently. Servers may rate-limit you. Your own page may run out of memory if you start a thousand image jobs.

A pool lets independent work stay independent while capping pressure. The implementation below starts a few workers. Each worker pulls the next index from shared state, awaits that item, and stores the result back into the original input order.

1async function mapWithLimit(items, limit, fn) {2  const results = new Array(items.length);3  let nextIndex = 0;4 5  async function worker() {6    while (nextIndex < items.length) {7      const index = nextIndex++;8      results[index] = await fn(items[index], index);9    }10  }11 12  const workers = Array.from(13    { length: Math.min(limit, items.length) },14    () => worker()15  );16  await Promise.all(workers);17  return results;18}

A waterfall is a chain where each async step waits for the previous step. Some waterfalls are real. User → posts → comments is dependent: you need the user before their posts, and a post before its comments. Others are accidental, like calling Ann, waiting for Ann, and only then calling Ben even though Ben did not need Ann’s answer.

1// Dependent waterfall: each line needs data from the previous one.2const user = await getUser(userId);3const posts = await getPosts(user.id);4const comments = await getComments(posts[0].id);5 6// Independent requests: start together.7const [profile, settings, notifications] = await Promise.all([8  getProfile(userId),9  getSettings(userId),10  getNotifications(userId),11]);

Where you’ll use this

You will make this choice in route loaders, dashboards, upload tools, migrations, form submit handlers, and build scripts. Ask three questions before adding await above another await:

1. Does the next operation need the previous value?
2. Would starting everything overwhelm a server, browser, or memory?
3. Do I need all successes, the first failure, or every settled result?

Common misconceptions

• “await blocks JavaScript.” It pauses the current async function; the event loop can keep doing other work.
• “Parallel means CPU threads.” Here it means overlapping host work like timers, network, and file operations while JavaScript waits.
• “Promise.all cancels losers.” It rejects fast but does not cancel other operations. Use cancellation APIs when cancellation matters.
• “map async gives values.” It gives promises. Await the group to get values.
• “Sequential is always bad.” It is correct for true dependencies, ordered side effects, and rate limits.
• “Unlimited parallel is always fastest.” Resource limits can make it slower or unreliable.

Key takeaways

• await in for...of is intentionally sequential.
• forEach does not wait for async callbacks.
• Start independent promises before awaiting, usually with Promise.all.
• Promise.all fails fast but does not cancel work already started.
• Use Promise.allSettled when every result matters.
• Use a concurrency limit when unlimited starts would overload resources.

Sequential waits in line; parallel starts together; a pool starts a sensible number together.

Up next: Cancellation with AbortController.