The Promise API and the Trust It Buys You
Why .then() isn't the point of promises, and the real trust guarantees baked into every promise: resolved exactly once, values locked, errors never silently lost.
Here's the actual idea this post teaches, in one sentence: a promise's real job isn't the .then() syntax, it's a short list of guarantees baked into every promise that a plain callback never gave you, and those guarantees are the actual fix for the trust problem.
Getting a promise back instead of handing away a callback already flips who's in control. Here's what that actually buys you.
Rewriting the Broken Checkout With a Promise
Remember Neal getting charged five times? Here's trackPurchase again, this time returning a promise instead of taking a callback.
function trackPurchase(orderDetails) {
return new Promise((resolve, reject) => {
// whatever this does internally, it ends by calling one of these:
resolve(orderDetails);
// or, if something went wrong: reject(new Error('tracking failed'));
});
}
trackPurchase(orderDetails).then(
function () {
chargeCard(orderDetails);
showThankYouPage();
},
function (err) {
console.error(err);
}
);Notice something: there are still callbacks here. Two of them, passed into .then(). If promises are supposed to fix the problem with callbacks, why are there more of them than before?
That's the right question to ask, and the answer is the entire point of this post.
The Callbacks Were Never the Problem
A promise can only ever end one of two ways: resolve, or reject. Not zero times. Not five times. Exactly once, one way or the other.
That single guarantee quietly answers most of the trust list from a few posts back.
Once trackPurchase calls resolve, that's final. Calling resolve or reject again does nothing. .then()'s first callback fires exactly once, no matter how many times something inside trackPurchase might have accidentally called resolve. The bug that charged Neal five times can't happen here, not because you wrote a guard for it, but because the promise itself refuses to let it happen.
The value handed to .then() is locked too. Nothing outside the promise can reach in later and swap it for something else, so it's genuinely safe to hand to any other part of your program.
And errors are never just dropped. If something inside a promise throws, that failure always becomes observable through .then()'s second callback. You can still choose not to check for it, but that's your choice, not the promise silently losing your error.
A Promise Is Also a Callback Manager
Here's a third way to describe what a promise actually is, after "future value" and "un-inverted control": a promise is a manager for your callbacks, one that enforces every rule you used to have to write yourself.
.then() doesn't remove callbacks from your code. It puts them behind a gatekeeper that already handles the five things you couldn't trust a plain callback to get right. You still write callbacks. You just don't have to defend against them anymore.
One Reason They Stay This Strict
There's a reason JavaScript never added a way to cancel a promise after handing it out. Picture handing a promise to three different parts of your program, and one of them decides to cancel it.
The other two would have no idea their value just vanished out from under them, broken by code they don't even know exists. Locking a promise's outcome the moment it settles is what makes it safe to hand to anyone, anywhere.
The API is real, and it matters. But it's downstream of this: a promise is a value you can finally trust, and everything about .then() exists to protect that one fact.
Keep reading