Callbacks, promises, and async/await: why Playwright needs all three

Open any Playwright test and the same two words are everywhere:

test("has title", async ({ page }) => {
  await page.goto("https://playwright.dev/");
  await expect(page).toHaveTitle(/Playwright/);
});

Why is the test body async, and why does every action carry an await? Answering that properly needs three concepts, in order: callbacks, then promises, then async/await. The first two are mostly here so the third makes sense, and so you can read older code that still uses them.

This is also the last stretch of plain JavaScript. After this the course moves to TypeScript and then to Playwright itself, so the effort now pays off twice.

A callback is a function you hand to another function, to be run when that function finishes.

The mechanics are ordinary: the second argument is just a function.

function placeOrder(item, callback) {
  console.log("Order placed for " + item);
  callback();
}

placeOrder("burger", function () {
  console.log("Order is ready, pick it up");
});

Output, in this order:

Order placed for burger
Order is ready, pick it up

The same callback can be written three ways, and they behave identically:

That last row is the point. Look again at the Playwright test at the top: async ({ page }) => { ... } is an arrow function passed as the second argument to test. Playwright's syntax is a callback you have already been writing without naming it.

Callbacks can also return values, which surprises people:

function calculate(a, b, operation) {
  return operation(a, b);
}
calculate(10, 12, (x, y) => x + y);   // 22

Not all callbacks wait for something. The distinction matters.

A synchronous callback runs immediately, line by line, and the program waits for it before moving on. Every map, filter and forEach callback is this kind:

const results = ["pass", "fail", "pass"];

results.forEach((result, index) => {
  console.log(`test ${index} ${result}`);
});
console.log("done");

test 0 pass
test 1 fail
test 2 pass
done

done prints last because forEach finishes every iteration before the next line runs.

An asynchronous callback says "do this later, carry on for now". The classic vehicle is setTimeout:

console.log("first");
setTimeout(() => console.log("after timeout"), 50);
console.log("second");

first
second
after timeout

The order is the lesson. second prints before after timeout, even though the timeout line comes first in the file. The callback was handed off and the program carried on rather than freezing.

setTimeout is only the simplest way to see the behaviour. It is the same behaviour you want for a network request or a page load, though Playwright does not expose it as timer callbacks: it hands you promises instead, which is the next section.

One or two callbacks are fine. The problem starts when each step depends on the one before it, which is precisely what a test does: open the browser, then go to login, then enter credentials, then click.

openBrowser(function () {
  goToLogin(function () {
    enterCredentials(function () {
      clickLogin(function () {
        console.log("test complete");
      });
    });
  });
});

Four steps and the code already drifts to the right. This shape has a name, coined long before Playwright existed: the pyramid of doom, also called callback hell.

At four steps it is ugly. At a real test with dozens of steps it is unmaintainable, and closing brackets like }); }); }); }); stop meaning anything.

Error handling is the one that really hurts. There is no single place to catch a failure, so each level has to handle its own.

A promise is JavaScript's way of saying "I will give you a result later, and it will either succeed or fail."

You build one with new Promise and a function that receives two callbacks, resolve and reject:

const foodIsReady = true;

const order = new Promise((resolve, reject) => {
  if (foodIsReady) {
    resolve("pizza delivered");
  } else {
    reject("order cancelled");
  }
});

order
  .then(result => console.log(result))     // runs on resolve
  .catch(error => console.log(error))      // runs on reject
  .finally(() => console.log("done"));     // runs either way

With foodIsReady true you get pizza delivered then done. Flip it to false and you get order cancelled then done.

The three handlers, precisely:

• .then runs when the promise resolves, and receives whatever was passed to resolve.
• .catch runs when it rejects, and receives whatever was passed to reject.
• .finally runs in both cases. It is the try/catch/finally idea in promise clothing.

Chained .then calls pass their return value along:

Promise.resolve(5).then(v => v * 10).then(v => console.log(v));   // 50
Promise.resolve(1).then(v => v + 1).then(v => v + 1);             // ends at 3

And a promise does fix the pyramid, up to a point:

openBrowser()
  .then(() => goToLogin())
  .then(() => enterCredentials())
  .then(() => clickLogin())
  .catch(err => console.log(err))
  .finally(() => console.log("test finished"));

Flat instead of nested, and one .catch for the whole chain instead of error handling at every level. Better. Still a lot of .then.

Three helpers come up often enough to know by name.

// all: one failure sends the whole thing to catch
Promise.all([Promise.resolve("auth ok"), Promise.reject("DB is down")])
  .then(r => console.log(r))
  .catch(e => console.log(e));          // "DB is down"

// allSettled: never rejects, tells you about each one
Promise.allSettled([Promise.resolve("passed"), Promise.reject("failed")])
  .then(r => console.log(r.map(x => x.status)));   // [ 'fulfilled', 'rejected' ]

// race: first to settle wins
const slow = new Promise(r => setTimeout(() => r("slow"), 300));
const fast = new Promise(r => setTimeout(() => r("fast"), 100));
Promise.race([slow, fast]).then(v => console.log(v));   // "fast"

These were worked through live. Cover the answers and try them first.

3. Each .then receives the previous return value, so 1 becomes 2 becomes 3.

The second .then is skipped and .catch runs. Throwing inside a handler rejects the chain from that point, so control jumps to the nearest .catch. This one came up in a real interview at a Bangalore company.

.catch and .finally, in that order. .then is skipped. finally does not care how it settled.

No, .catch runs. all demands that every promise succeeds. Use allSettled when you want the results either way.

Chaining .then is better than nesting callbacks, and still noisy. So JavaScript added two keywords.

• async goes in front of a function. That function now returns a promise.
• await goes in front of any expression that returns a promise. It pauses at that line until the promise settles, then hands you the value.

The login flow, one more time:

async function runLoginFlow() {
  await openBrowser();
  await goToLogin();
  await enterCredentials();
  await clickLogin();
  console.log("test complete");
}

No nesting, no .then, no drift to the right. It reads like synchronous, top-to-bottom code and behaves asynchronously underneath. That is the whole trick.

Two rules that follow from the definitions:

• In a Playwright test, await lives inside the async callback. Top-level await is also legal in ES modules, but inside a test the two always travel together.
• Anything returning a promise can be awaited. You do not need to know how it was built.

Everything a browser does takes time. Navigating to a URL, clicking a button, waiting for a network response. None of it is instant, so none of it can be synchronous without freezing. The same is true of work your test does outside the browser, such as opening a database connection.

That makes every Playwright action promise-returning, which is why the test body is an async arrow function and why each action is awaited:

test("has title", async ({ page }) => {
  await page.goto("https://playwright.dev/");
  await expect(page).toHaveTitle(/Playwright/);
});

Read it with today's vocabulary: test takes a callback, that callback is an arrow function marked async, and each line inside awaits a promise. Three concepts, one line of test code.

The standing instruction for the rest of the course:

• Use async and await. This is the default and the house style.
• Do not write callback pyramids. They exist so you can read old code, not so you can write new code.
• Do not chain .then when an await will do.
• Promises still appear, mostly inside helpers. Libraries such as Axios already return a promise, so a helper usually just returns it and the test awaits the helper. Reach for new Promise only when you are wrapping something that does not return one already.

• Today's task: practise. Around 147 exercises on callbacks and promises are being added to the class GitHub repository.
• Tests are starting. Multiple MCQ tests covering the JavaScript parts, plus live coding tests. Attendance is mandatory; Deepak is organising them. The async and await test comes in a later session.
• No class on 15 August, Independence Day.
• Doubts go in the doubt thread, not direct messages, so the answers reach everyone. An evening doubt-clearing session is being planned.
• Coming next: the remaining JavaScript topics, then TypeScript, then Playwright itself.
• Today's code has been pushed to the class repository.