Callbacks, and why they exist

You already store numbers in variables. JavaScript treats a function the same way. When you write `function shout(text) { ... }` you have not only described some behaviour, you have created a value and given it the name `shout`. You can copy it into another variable, put it in an array, or hand it to another function — all without calling it.

The difference between `shout` and `shout("hi")` is the whole idea. `shout` is the function itself: the recipe, sitting on the shelf. `shout("hi")` is the result of running it: the meal. Write the parentheses and it runs right now. Leave them off and you are just passing the recipe along.

A function that you hand to another function, so that the other function can call it, is called a callback. That is the entire definition. It is not a special kind of function and there is no keyword for it — it is a job description, not a type.

Imagine ordering at a busy bakery. One option is to stand at the counter until your bread comes out. You get the bread, but you cannot do anything else while you wait, and the queue behind you cannot move.

The other option is to leave your phone number and go and do your shopping. The bakery has your number — it has your callback. When the bread is ready, they call you. You did not have to stand there, and the queue kept moving.

That second shape is what callbacks buy you. You say what should happen with the answer, hand that instruction over, and get on with something else. The catch — the thing this whole module exists to teach — is that the bakery decides when to phone, not you.

This trips up nearly everybody, so read it twice: most callbacks in JavaScript run immediately. `[1, 2, 3].map(n => n * 2)` takes a callback and calls it three times before `map` returns. Nothing is delayed. Nothing is scheduled. It is an ordinary function call inside a loop.

MDN puts callbacks in two groups. A synchronous callback is called during the outer function's own run, with nothing asynchronous in between. An asynchronous callback is called at some point later, after some operation has finished. Same word, two completely different timings, and the word alone will not tell you which one you have.

This matters more than it sounds. If a callback is synchronous, you can be sure it has finished by the time the outer call returns, so anything it assigned is ready to use on the next line. If it is asynchronous, the next line runs first and that variable is still empty. Reaching for a value that has not arrived yet is the single most common asynchronous bug there is.

When you meet a function that takes a callback, ask one question: has the outer function already returned by the time my callback runs?

If the answer is no — the callback runs while the outer function is still on its way — it is synchronous. `map`, `filter`, `forEach`, `sort` and every function you write yourself in this lesson are in this group.

If the answer is yes — the outer function returned long ago and your callback fires afterwards — it is asynchronous. Timers, network requests and file reads are in this group. You cannot tell which group you are in by looking at the callback. You have to know what the outer function does, which is why the documentation for that function is the thing to read.

A cheap way to check in real code: print something right after the call. If your callback's output appears before that line, it is synchronous. If it appears after, it is not. You will do exactly that in the worked examples below.

There is a convention you will meet constantly, especially in older code and in Node.js: the callback takes two parameters, and the first one is the error. Success calls `callback(null, value)`. Failure calls `callback(someError)`.

The reason for the convention is that an asynchronous function cannot report failure the way an ordinary function does. By the time the network request fails, the function that started it has already returned, so there is nobody left to `throw` at — the `try` block that surrounded the original call finished ages ago. The error has to travel the same route as the answer: through the callback.

Because the error comes first, the honest way to write the handler is to deal with it first: `if (error) { ...; return; }` and only then touch the value. Putting the error check first, with an early return, is what stops the success path from running on data that was never produced.

Calling instead of passing. `eachItem(list, myHandler())` runs `myHandler` immediately and passes its return value — usually `undefined` — as the callback. You wanted `eachItem(list, myHandler)`, with no parentheses. If you get "is not a function" from inside the outer function, look here first.

Ignoring the error argument. `function (error, value) { console.log(value); }` looks fine and hides every failure, because on failure `value` is `undefined` and nothing complains. Check `error` first or do not accept it at all.

Calling the callback twice. Forgetting a `return` after the failure branch means execution falls through and the success branch calls the callback again. The caller then handles one request twice, which is much harder to debug than a crash.

Assuming the callback already ran. `let result; getThing(cb); console.log(result);` prints `undefined` for every asynchronous `getThing`. The fix is never to move the `console.log` around until it works — it is to move the code that needs `result` inside the callback.

Promises and `async`/`await`, which fill the rest of this module, are not a replacement for the idea of a callback — they are a better container for it. `.then(handleResult)` is still handing a function over for somebody else to call. If passing functions around feels solid, the rest of the module is a change of spelling. If it does not, promises will feel like magic, and magic is impossible to debug.

There is also a practical reason. Nesting callbacks works for one step and gets unreadable at three: each step adds a level of indentation and repeats the same error check, and there is no way to say "do these two at the same time" without writing a counter by hand. Promises exist because of those specific pains. You will appreciate the cure much more having felt the disease.

A function is a value; pass it without parentheses. A callback is just a function that somebody else calls. Most callbacks run immediately — ask whether the outer function has returned yet, and prove it with a print statement rather than guessing. Error-first callbacks put the failure in the first parameter, so handle it first and return. Everything after this lesson is the same idea in a tidier package.