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
Skill Level Intermediate
(string and flute electronica music) - As a quick intro for anyone that may be joining us on video, or someone that hasn't heard of me before, just a quick intro.
My name's Kyle Simpson, known as Getify, and I can be found Getify at all the major places, like Twitter and GitHub, Gmail, all those other places. I list this stuff, because I encourage you to reach out and provide feedback or ask questions, if you're going back over this stuff, particularly the stuff that we'll be going through through the course of this workshop and there's a lot of depth here, especially as we get further into it. The exercises become extremely challenging. There are exercises that took me weeks to work out, and then I'm expecting you to do them in like 20 minutes, so they're extremely challenging on purpose.
Just trying to push your understanding of asynchronous patterns. So if you have questions about that or if you're struggling with that, please feel free to reach out. I'd love to help you with that. Just real quickly, I've done several open source projects, LABjs, scriptloader, grips is a templating engine, asynquence, we're going to spend a lot of time talking about asynquence actually, but not because I'm trying to sell you on that library, simply because it is designed to help make asynchronous programming concepts easier to understand and manage in your brain, it's designed to make them easier to teach. So you'll get some exposure to asynquence as we go throughout this workshop.
I am the head of curriculum for MakerSquare, for about the last three or four months. MakerSquare is a developer-engineer training school. We have campuses in Austin, San Francisco, and Los Angeles, and we will be expanding as well. We take you from junior level status to intermediate status, and that's slightly different than other schools which may say, "we start you from nothing "and get you to junior level status." We're more on the higher end, we like to kind of think of ourselves more like the MIT of these developer schools. So you start out at a higher level, more is required of you, but we also take you a lot further.
You should be able to find quite a bit of coverage of some of these topics in those books. The entire six book series, 1100 pages worth, is available for free online at GitHub. This YouDontKnowJS.com will redirect to that. You can also purchase them. They've been edited and published through O'Reilly so you can purchase them if you're happy with that content. Today we are going to talk about asynchronous patterns. Now, I want to explain right off the bat that my approach to this, much like my approach to the other things that I teach, is to first focus on the concept before explaining the how to use something.
That differs from some of my peers who first would present to you the API for something and then maybe perhaps later you might pick up on some of the conceptuals behind it. I think it's more effective for you to understand why you do something a certain way before actually getting too immersed in the actual doing of the thing. So, for example, some of you listening probably are at least somewhat familiar with promises, but I'm not sure everyone has had a very good conceptual grounding in what a promise really is and why a promise is useful.
'cause I see an awful lot of arguing about promises in the opensource community and they seem to focus an awful lot on bickering about the API for promises, and missing out on the deeper point of why they even exist. So, for each of the topics that we're going to go through today, our goal is to build up a conceptual understanding first and then a practice of why we do the thing, of doing the thing once we know why we do it. So we're going to actually start, even before we talk with some code, we're going to start understanding a very important distinction that is often conflated.
Two major deficiencies, in fact, that I would use to define the notion of callback hell. Callback hell is thrown around an awful lot and most people, when I say that term, what evokes in their mind is that it has something to do with indentation, with nesting, things like that. What I'm going to show you is that callback hell has actually almost nothing to do with indentation and nesting. There's something much deeper, much more important, to understand about callback hell. So we're going to look at callbacks and look at why, how they work first, we'll get some practice with them just to understand that, kind of some first-person experience with the pain of that.
I'm sure you all have that already. But then we're going to look at what those problems are, give them a name, give the problems of callback hell a name, and we're going to look. And that will be our motivation to why we want to try to solve those problems with these higher order patterns. Another variation on callbacks that we're going to look at, which is kind of interesting, it has not gotten a lot of attention, many of you may not have even heard before, but thunks. Thunks are something that I even just sort of recently myself, and by recently I mean within the last year or two, discovered this pattern and realized, wow, I really wish I had been able to articulate that pattern years ago.
Because, actually, it's a really good precursor to understanding what promises are about. So we'll look at thunks and we'll look at why they are part of that tool. They're one of the little tools you should have in your tool set. Having that conceptual understanding of what a thunk really is and what it's useful for, that will bridge us into promises. In other words, thunks are kind of like promises without the fancy API. So once we get the conceptual grounding in thunks, we'll understand why promises are useful. We'll look at the APIs for how to use promises. We'll look at some patterns for them.
All along the way, every one of these patterns, we're going to be revisiting an exercise, the exact same exercise over and over and over again. And you're going to reimplement the solution to that exercise using every single one of these patterns, from callbacks all the way up. The goal there being that you will be fully understanding, you don't have to worry about the problem demand anymore, you'll be fully understanding the pros and cons of each of these patterns. So that's how we'll go about it. So we'll be looking at promises. Then we're going to look at generators and coroutines. And by the time we've looked at promises and generators, we actually will have established two solid solutions to those major issues of callback hell.
That represents the base line. The point at which, if you're ready to tune me out, and I've overwhelmed you, or you're bored, or whatever, you got to get this part. You got to get through the promises and generators. That is the new base line for competency in asynchronous programming, is understanding what promises are, what generators are, and why the two need to be mixed together to solve the issues of callback hell. That's the new standard for competency. So that's really if you get nothing else out of the workshop I want to make sure everybody gets to that point.
I'm like no it's probably not. As a matter of fact, it's almost certainly not. There's no one silver bullet that replaces everything else. So nothing that I'm teaching you today is going to be replacing everything else that we've talked about. Rather, you should consider these things, instead of ors, you should consider them ands. This is additive. These are additional tools, additional patterns. And you can develop instincts for why one pattern is more well-suited for a particular set of problems. My programs try to efficiently use each of these different patterns where necessary.
Even things like callbacks and thunks have their place. Promises have their place, generators have their place. In addition, when we start dealing with event streams, we'll find that promises actually don't really give us a very good solution when we start dealing with event-oriented programming, what I call event-reactive, or reactive sequences. That also goes by the name observable. So if you've read anything, there's been a buzz recently. There's quite a bit of information out there about this notion of observables. There's a library for Microsoft called RxJS, one of the most common implementations of the observable pattern.
So I'll show you what that pattern's about, why it's useful. We will relate that back to and practice with the expression of observables in the asynquence library 'cause that'll be easier for us to play with without learning a huge library with hundreds of methods. So a very small subsection of that, we'll play with in asynquence that I call reactive sequences, does basically the same thing. So that's a higher order pattern that will help us put all the other stuff that we've learned together in interesting ways and solve event-oriented programming, event-oriented asynchronous programming.
And finally, the last pattern that we'll look at, very high level pattern, hasn't gotten a lot of attention recently, but it's called CSP. It stands for communicating sequential processes. This is not a new concept, actually it was invented in the early 60s. And... It was developed and thought about by some really really smart people, way smarter than I am. So there's nothing new that I'm presenting here, no new information, that hasn't been talked about for decades. But it almost feels like CSP is on the cusp of a rediscovery in particular because recently we've seen some more popular, more mainstreamish type languages, adopt this model for concurrency.
Kind of, maybe. There are some places that it's really good and some places that it's not so good. And then I've heard people say, "well you don't even need promises "'cause you could do everything with a CSP channel." Okay, but there's places where that's useful and places where it's not. So this is not an all or nothing thing, but CSP is a fundamentally rather undiscovered or rather untalked about sort of pattern. But I'm kind of convinced that it represents kind of the next next wave. If the big wave is observables, if that's about to wash over us, the one after it is CSP.
So I want us to be aware of those things and understand how all these tools weave together. By the end of this we'll be working through some rather challenging exercises trying to push our brains into thinking way beyond just a simple callback, okay? So that's where we're going with this workshop. If things seem too simple at the beginning, I promise you by the end there'll be plenty to be digging your teeth into.