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 frustrating callback scenarios and makes the argument that the classic sideways pyramid shape has nothing to do with the inherent problems created by callbacks.
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 time out, and then after a thousand milliseconds, execute the console.log statement. 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's 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's working. But another thing to think about is that this function is often times referred to as a continuation because there's a first half of our program and a second half of our program here. It may not be obvious to you but the first half of the program is everything on the outside of the timeout, including the setTimeout 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 going to 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 wrapped 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. How many of you have heard that term callback hell before? Sure many of you will probably raise your hands in the online chat as well. Callback hell, it's one of those shared things, it's almost like we can have a counseling session about all the nightmares we've had with callback hell, right? It's usually thought of as having something to do with this idea of nesting.
In fact, sometimes it's referred to as the pyramid of doom because of that pyramidal shape, triangular shape to our code. But is that what 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 who would describe 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 what 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, than 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 name 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 that 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 in 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.
Note: This course was created by Frontend Masters. It was originally released on 3/29/2016. We're pleased to host this training in our library.
- Parallel and asynchronous code
- Working with callbacks
- Using thunks
- Exploring promise flow control
- Abstractions, sequences, and gates
- Observables, events, and sequences
- Blocking channels