Promises looked like syntactic sugar for callbacks. They're actually a different mental model for asynchronous flow, and understanding that difference took me months.

#JavaScript #Async #Promises

Callback Hell

Before I understood promises, I wrote asynchronous JavaScript the way everyone did in the jQuery era: nested callbacks. You call an async function, pass it a callback that runs when the async operation completes, and if you need to do another async operation after the first one, you nest another callback inside the first. Two levels of nesting is manageable. Three levels is awkward. Four levels produces a pyramid of code that's genuinely hard to read, and five levels — which I wrote, more than once — produces code that is effectively write-only: you can write it, but you can't read it afterward, and debugging it requires tracing through five layers of closure scope to figure out where a variable's value comes from.

The problem with nested callbacks isn't just readability — it's error handling. In a callback-based system, errors have to be propagated manually: every callback has to check for an error argument and either handle it or pass it to the next callback's error handler. Forget to check in one place, and an error silently disappears, surfacing later as an undefined variable or a missing UI update that nobody can trace back to its source. I spent days debugging issues that were, at their root, unhandled errors in callback chains that had been written weeks earlier and that nobody could fully trace through anymore.

Understanding Promises

Promises solved both problems, but the solution took me a while to internalize because promises aren't just a different syntax for callbacks — they're a different mental model. A promise represents a value that will exist in the future, and you interact with it by calling .then() to say what to do when the value arrives. The key insight is that .then() itself returns a promise, which means you can chain .then() calls instead of nesting them, and the chain reads top-to-bottom in the order the operations execute. That top-to-bottom readability is the entire point of promises, and it's what makes a five-step async flow readable in a way that a five-level nested callback never could be.

Error handling in promises is where the model really shines. Instead of manually checking for errors at every step, you attach a single .catch() at the end of the chain, and any error from any step propagates to that catch. That means you write error handling once, at the end, and it covers every step in the chain. The cognitive load reduction is substantial — instead of thinking about "what can go wrong at each step and how do I handle it," you think about "what can go wrong in this flow and how do I handle it," which is a higher-level and more useful framing.

Async/Await

Async/await was the next step, and it made asynchronous code look synchronous — you write const data = await fetchData() instead of fetchData().then(data => ...), and the code reads as if the async operation were blocking even though it isn't. The readability improvement is real, but async/await also introduces subtleties that catch people off guard. The most common one is sequential execution of operations that could run in parallel: if you await three independent API calls one after another, the total time is the sum of the three call durations, when it could be the maximum of the three if you used Promise.all. That's a performance bug that doesn't show up in code review because the code looks correct — it's just slower than it needs to be.

Error handling in async/await uses try/catch, which is familiar to anyone who's written synchronous JavaScript, but the catch is that a try/catch around an await only catches errors from that specific await. If you have multiple awaits in a row and want to handle all their errors the same way, you either wrap them all in one try/catch (which works but conflates the error sources) or you use individual try/catch blocks (which is verbose). The right pattern depends on the situation, and learning to choose well is part of writing good async code. Promises and async/await are the same thing under the hood — async/await is syntactic sugar over promises — but the sugar changes how you think about the code, and that change in thinking is what makes async/await worth using once you understand the underlying promise model.