Check out a free preview of the full Rethinking Asynchronous JavaScript course

The "Callback Hell" Lesson is part of the full, Rethinking Asynchronous JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

Kyle describes callbacks as a continuation of code. One part of the program executes, then later, another part of the program continues. He also introduces “callback hell” and makes the argument that the classic sideways pyramid shape has nothing to do with the inherent problems created by callbacks.


Transcript from the "Callback Hell" Lesson

>> [MUSIC]

>> Kyle Simpson: We're going to look at some problems with callbacks. We're gonna get some practice with them and then I'm going to articulate to you the real essence of what callback hell is about. But I wanna look at some issues with callbacks. So easiest, simplest expression of a callback in an asynchronous fashion.

We pass the function as a callback to another utility. This one happens to be built in to the JavaScript engine but it could have been some other utility in our code. We pass the callback in. Now if we were to describe what this function does or how this function operates, we might say something to the effect of set up a timeout.

And then after 1000 milliseconds execute the console.log state. Most people would probably nod in agreement that's roughly how we would describe the behavior of this program. Unfortunately that description is fundamentally insufficient. There is a deep deficiency there, in our ability to understand and reason about, and describe and articulate what's happening.

So one of the issues that we have is that our brains are not actually working in the same way that the code is working. But another thing to think about is this function is oftentimes referred to as a continuation because there's a first half of our program and a second half of our program here.

May not be obvious to you but the first half of your program is everything on the outside of the timeout including the set timeout call itself. And the second half of your program is everything inside of the callback. In essence there's a general concept of a now, the stuff that's gonna happen immediately right now, and a later.

For some definition of later, which we don't care about. We don't care what the real definition of later is, we just know it's not immediately after what I'm doing at the moment. There's some gap, and that gap could be a zero millisecond delay, whatever that means. It could be waiting for an Ajax request, it could be waiting for a message from a web worker.

Who knows? But understanding this notion of now and later, there's a first half and a second half. When we refer to functions as continuations, what we mean is, we did the first half of our program now, and we wrap the second half of our program up in a callback.

And we deferred that callback to happen until later. And at that later moment, we're going to pick up and continue our program from where we left off. So that's where we get the term continuations for callbacks.
>> Kyle Simpson: How many of you have heard that term callback hell before?

I'm sure many of you will probably raise your hands in the online chat as well. Callback hell, it's one of those shared things almost like we could have a counseling session about all the nightmares that we've had with callback hell, right? It's usually thought of as having something to do with this idea of nesting.

And that sometimes is referred to as the pyramid of doom because that pyramidal shape, triangular shape to our code. But is that we callback hell really is? I think it's much, much, much deeper than that. I would go so far as to say, and this isn't intended as an insult, but I would go so far as to say there's an awful lot of my peers out there that have described callback hell as having to do with the indentation in the nesting.

My response is I don't think you've thought very critically about what callbacks are really about and callback hell is about. This is where I might differentiate from some of my peers in that I'm much more focused on the concepts here, even than the actual observations in the actual code.

There's something conceptually deficient here. There's two conceptually deficient problems. I can start out proving to you that it doesn't really have anything to do with nesting and indentation by observing to you that this program does in fact suffer from callback hell. But I can rewrite this program in a different style, sometimes referred to as continuation passing style.

And this code is not nearly as obviously suffering from nesting and indentation problems, is it? We've used named function declarations rather than inline function expressions. If you look really close you can still see the fundamental nesting going on but we don't have the same pyramidal shape to our code.

And most people that took a glance at this code would not naturally instinctively think callback hell. But that's why callback hell needs to have a redefinition on our minds, because this code is every bit as susceptible to callback hell as the previous code. Even though the style looks different, it still has those same problems.

We need a more nuanced, a deeper view of what callback hell is about.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now