Inversion Of Control

The last post left a question hanging: what actually happens to your control the moment you hand a callback to code you didn't write? That question has a name: inversion of control.

Now, Later, and Who's in Charge

A callback splits your program into "now" and "later." The part you're not in control of is "later," because you handed that half over to someone else, and they decide when and how it actually runs.

With a built-in like setTimeout, that's usually fine. The JavaScript engine is reliable, so you don't spend time worrying whether your timer callback will fire twice, or never, or with the wrong arguments.

Hand that same callback to someone else's code, and every one of those guarantees disappears. "Someone else's code" doesn't have to mean a third-party library either, it can just as easily be a different part of your own codebase that you didn't write this particular callback to trust.

A Trust Problem With a Real Cost

Picture building checkout for a store that sells expensive furniture. The last step, right after a customer clicks "buy," calls a third-party tracking utility. It logs the purchase for analytics, then calls your callback so you can charge the card and show a thank-you page.

It works in testing. It works in production, for months.

Then one morning, a customer named Neal gets charged for the same sofa five times. He posts about it. Support escalates it to your team, and nobody remembers writing anything that should let that happen.

The cause, once you find it, isn't in your code at all. The tracking utility briefly shipped an experimental retry: if it didn't get a fast enough response, it called your callback again, up to five times, once a second. It was live for five minutes. Neal's checkout happened to land in that window.

You didn't write a bug. You trusted a callback to behave a certain way, and it didn't.

The List of Things You're Quietly Trusting

Every single callback you've ever passed to someone else's code carries an unspoken list of promises, none of which JavaScript enforces for you:

• It gets called, not zero times.
• It gets called only once, not more.
• It gets called at the right time, not too early, not too late.
• It gets called with the right arguments, intact.
• It doesn't quietly swallow an error that should have reached you.

ExpandYour code hands a callback to someone else's code, which decides when, how, and how many times it runs, without JavaScript enforcing any of five unspoken guarantees.

You'd never accept an unverified assumption like this from a plain function argument. A function that adds two numbers usually checks that it actually received numbers first. A callback gets none of that scrutiny, by habit, not by necessity.

Why Patching One Case Doesn't Fix the Problem

The obvious fix for "called too many times" is a flag: set it to true the first time the callback runs, and refuse to charge the card again if it's already true. That solves the exact bug Neal hit.

It solves nothing else. What happens if the callback is never called at all, and the customer just sits on a frozen checkout screen forever? That's a different trust failure, and the flag does nothing for it.

Multiply this by every callback in a real codebase, and hand-patching each one individually stops being realistic. A codebase that tries to guard every callback this way by hand can easily double or triple in size, just from defensive checks that exist purely to compensate for trust the language never actually gave you. Any program with a callback that has no answer for these trust issues has a live bug in it, whether or not it's been triggered yet. What's actually needed is a pattern built specifically to guarantee these things, not another one-off patch.

The Essentials

1. Inversion of control is handing the "later" half of your program to someone else, trusting them to run it correctly.
2. A callback carries an unspoken list of guarantees: called once, not zero or many times, at the right time, with the right data, errors surfaced rather than swallowed.
3. Plain callbacks enforce none of these guarantees. Nothing in the language checks that the code you handed control to actually behaves.
4. A fix for one trust failure (called twice) does nothing for a different one (called never). Ad hoc patches don't generalize.
5. A callback with no answer for these trust issues is a live bug, even before it's ever been triggered.

Inversion of control is one of two real problems underneath callback hell. The other is about whether a human being can actually trace what this code does, and that's next.