How Do Callbacks Pass Behavior?

A callback is a function you hand to another function so it can call it later. It is how JavaScript passes behaviour into code that only knows how to do one thing. The receiving function decides when to call it and with what, and the caller decides what the behaviour is.

function run(task) {
  console.log("before");
  task();
  console.log("after");
}

run(() => console.log("work"));

// The same function reused with different behaviour:
function applyToAll(items, fn) {
  return items.map(fn);
}

console.log(applyToAll([1, 2, 3], (n) => n * 10));   // [10, 20, 30]
console.log(applyToAll([1, 2, 3], (n) => `#${n}`));   // ["#1", "#2", "#3"]

Because the behaviour arrives as an argument, the receiving function stays generic. The array map method does not know anything about multiplying numbers or formatting labels. It knows how to call a function once per element and collect the results, and the caller decides what that function does. That separation is the reason higher-order functions became the backbone of functional style in the language.

Callbacks also carry the notion of timing. The callback is not necessarily called immediately. It might be called later, after a timer, after a network response, or after a user event. The receiving function owns the schedule, and the callback just reacts when it is invoked. That is exactly how the built-in array methods work: they call your function synchronously as they walk the array, but a method such as setTimeout calls yours later.

Two practical points. A callback that is expected to be called more than once, or not at all, needs a clear contract, and the error-first convention is the traditional way to signal failure. And a callback that is passed straight through to another API should be wrapped in an arrow function when you need to add behaviour, so the extra arguments do not leak through.

The biggest problem is nesting. Each callback that needs the result of the previous one has to be written inside the previous one, so a sequence of five dependent steps becomes five levels of indentation, and the error handling has to be repeated at every level. This shape is called the callback pyramid, and it becomes unreadable fast.

// The traditional error-first callback contract.
function readValue(source, callback) {
  setTimeout(() => {
    if (source === "broken") {
      callback(new Error("cannot read " + source));
      return;
    }
    callback(null, "value from " + source);
  }, 0);
}

readValue("file", (err, value) => {
  if (err) {
    console.log("failed:", err.message);
    return;
  }
  console.log("ok:", value);
});

readValue("broken", (err, value) => {
  if (err) {
    console.log("failed:", err.message);
    return;
  }
  console.log("ok:", value);
});

Three specific complaints come out of that shape. The error-first convention puts the error in the first argument and the value in the second, which is unusual and easy to get backwards. The same error check is repeated at every level, and forgetting one means a failure is swallowed silently. And there is no way to say wait for two of these at once and continue when both are done, which is exactly what promises were designed to add.

A promise fixes all three. The result becomes a value you can pass around and chain, errors are caught once at the end of the chain, and the combining helpers let you run several asynchronous operations and wait for all of them. The same sequence becomes a flat list of steps with no indentation.

The honest caveat is that promises are not a strict upgrade in every case. They change the control flow model, they need a microtask tick before their handlers run, and a callback is still the simplest choice for a single, self-contained asynchronous step.

A function that takes a callback and calls it is the simplest possible higher-order function. The only design decision is what to do when the caller does not supply one.

function greet(name, callback = (message) => console.log(message)) {
  callback(`Hello, ${name}`);
}

greet("Ada");                                  // "Hello, Ada"
greet("Bob", (m) => console.log(m.toUpperCase()));   // "HELLO, BOB"

Giving the callback a default means the caller is not forced to supply one. The default is a function, so calling it still works; the default just happens to print instead of handing the message back to the caller.

Two variations worth mentioning in an interview. The callback could receive more than one value, which is common for a result and a status, and you should then pass the values along in a fixed order and document it. And if the callback might be called more than once, for example when the function retries, that contract has to be stated clearly, because a caller that assumes a single call will produce the wrong result.

The other design choice is whether to return the callback's return value. Returning it lets the caller use the result, but it also quietly assumes the callback runs exactly once and synchronously. A more robust contract returns nothing and communicates the result purely through the callback.