Callback in JavaScript: passing a function to be run later

Before promises, the language still needed a way to say: here is what should happen once this is ready. The answer is a simple idea, and one as old as JavaScript itself.

You hand over the rest of the work as a function, and the code you called decides when to fire it.

Definition

A callback is a function passed as an argument to another function, which takes care of calling it. It does not run where you write it, it is handed over.

const users = ["Chloe", "Marc", "Ines"];

// Called right away, once per item
users.forEach((name) => console.log(name));

// Set aside, and called one second later
setTimeout(() => console.log("One second went by"), 1000);

Both lines go by the same name and do nothing alike. Array.forEach() calls back immediately, setTimeout() calls back later. The difference never shows in the syntax, only in the documentation of the function receiving it.

The error-first convention

An operation that can fail has to be able to report that failure. Node.js settled on a rule that became a standard: the callback receives the error as its first argument, the result as its second.

function readConfig(path, callback) {
  if (!path) return callback(new Error("Missing path"));
  callback(null, { theme: "dark" });
}

readConfig("app.json", (err, config) => {
  if (err) return console.log("Failed:", err.message);
  console.log(config.theme);   // dark
});

The null in first position means nothing broke. A callback that never tests err swallows failures in silence, and that is by far the most common defect of this style.

The pyramid, and why we left it behind

A callback inside a callback inside a callback: every step pushes the next one further right, and the error test repeats at each level.

readConfig("app.json", (err, config) => {
  if (err) return console.log(err.message);
  readProfile(config, (err, profile) => {
    if (err) return console.log(err.message);
    readInvoices(profile, (err, invoices) => {
      if (err) return console.log(err.message);
      console.log(invoices.length);
    });
  });
});

A Promise fixes both problems at once: the run of steps flattens back out with then(), and a single catch covers the whole chain. With async and await, only three lines remain and they read top to bottom.

Frequently asked questions

No, and the confusion is a stubborn one. The callback given to forEach or map runs immediately, in place, before the next line. The one given to setTimeout waits its turn. The word says nothing about timing: you have to look at what the receiving function does with it.

Because a classic function gets its this from the way it is called, and the code calling it back calls it with no context at all. An arrow function settles the matter: it has no this of its own and keeps the one from the place where it was written.

Yes, because it is everywhere: browser events, array methods, older libraries you still run into. Understanding callbacks also makes promises far clearer, since promises only organize the very same idea. Both styles are worked side by side in the JavaScript course.