Rethinking Asynchronous JavaScript

Course Introduction

Kyle Simpson

Kyle Simpson

You Don't Know JS
Rethinking Asynchronous JavaScript

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

The "Course Introduction" 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 Simpson (@getify) begins his course on Async Patterns with a brief introduction of himself and an overview of the course agenda. He runs a few open source projects like LabJS, Grips, and Asynquence. He is also the head of curriculum for the developer/engineer training school Maker Square.


Transcript from the "Course Introduction" Lesson

>> [MUSIC]

>> Kyle: As quick intro for anyone that maybe joining us on video or someone that hasn't heard of me before, just a quick intro, my name is 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.

Be going back over the stuff particularly the stuff that will be going through through the course of this workshop and there's a lot of depth here especially as we get further into it it's 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 20 minutes.

So they're extremely challenging on purpose. I'm 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, script loader, grips as a templating engine, asynquence.

We're gonna 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 is designed to make them easier to teach. So you get some exposure to asynquences as we go throughout this workshop.

I am the head of curriculum for Maker Square for about the last three or four months. Maker Square 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 for 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, it's more as required of you but we also take you a lot further to Full-Stack JavaScript school so we teach all the front end Frameworks like the angulars and reacts and all the backend things like Mongo and Node and Express and things like that.

[COUGH] If you have any questions or thoughts about tech schooling or you know somebody that's interested or has some questions please put them in touch with me I'd love to chat with you more about that. I've written a series of books on JavaScript called You Don't Know JS.

A lot of what we're gonna talk about today is covered in some way shape or form in those books. Particularly, the Async and Performance book, as well as the ES6 book. You should be able to find quite a bit of coverage of some of these topics in those books.

The entire 6 book series 1,100 pages worth is available for free online at GitHub. You don't know 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 wanna 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 were 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 already 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, cuz I see an awful lot of arguing about promises in the open source 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 gonna go through today our goal is to build up a conceptual understanding first and then in practice of why we do the thing, of doing the thing once we know why we do it.

So we're gonna actually start even before we talk with some code. We're gonna start understanding a very important distinction that is often conflated. We're gonna look at the notion of parallelism versus asynchronicity. This is really speaking to the idea of concurrency. So we're actually gonna dig into what concurrency really means, specifically, what it means to a JavaScript developer.

Cuz that is the motivation by which we do all the rest of the things. Then we're gonna turn our attention to callbacks, the most fundamental premise of all of, the fundamental unit of asynchronous programming. And what we're really gonna see is that callbacks, while capable of expressing everything that we need.

Have some very significant deficiencies. 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 gonna show you is that callback hell is 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 gonna look at callbacks and look at how they work. First, we'll get some practice with them just to understand that kind of some first first person experience with the pain of that I'm sure you all have that already.

But then we're gonna look at what those problems are give them a name, give those pro gear the problems callback hell a name. 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 is not gotten a lot of attention.

Many of you may not even heard before but thunks. Thunks are something that I even just sort of recently myself and I 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 center. 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 kinda like promises without the fancy API. So once we get the conceptual grounding in thunks will understand why promises are useful. We'll look at the APIs for how to use promises, we'll get 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 gonna re-implement 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 understand you don't have to worry about the problem domain anymore you be fully understanding the pros and cons of each of these patterns.

So that's how we'll go about it. So we're looking at promises. There were no good generators in co-routines. And by the time we've looked at promises in generators we actually will have a established two solid solutions to those major issues of callback hell. That represents the baseline. The point at which if you're ready to like tune me out.

I have wronged you or you're bored or whatever. You gotta get this part. You gotta get through the promises and generators. That is the new baseline for competency. And 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 call.

That's the new standard for competency. So that's really if you get nothing else out of the workshop I wanna make sure everybody gets to that point. So we'll spend plenty of time making sure we get to that point. But that's not all because there's more to asynchronous programming that those patterns aren't necessarily good at.

There are more variations. Point that I'm making is, I have never once I've written a lot of code in my 17 years in JavaScript. I've never once written an entire program using exactly the same abstraction everywhere. There is no one silver bullet. Anytime somebody starts to tell me something like X is the new Y, my BS radar goes off I'm like no it's probably not, as 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 all wars you can still 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 a reactive sequences.

That's 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 from Microsoft called, RXJS, one of the most common implementations of the observable pattern. I'll show you what that patterns about why it's useful.

We will relate that back to in practice with the expression of observables in asynchronous library cuz that will be easier for us to play with without learning a huge library with hundreds of methods. So a very small subsection of that will play with an asynchronous 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 will look at very high level pattern. Hasn't gotten a lot of attention recently but it's called CSP.

It's 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 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 rediscovering. In particular because recently we've seen some more popular, more mainstream type languages adopt this model for concurrency. Namely the Go language uses the CSP model for concurrency as well as closure and closure script, closure script being the bridge that brings closure into the Into the JavaScript world in the browser.

So more and more people are starting to move into the Go programming language world and into Clojure and ClojureScript. And they're discovering that CSP is this really powerful pattern for managing concurrency. And I have heard people on the observable side for example tell me observables are that silver bullet.

You can model everything with an observable. Yeah, 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 because you can do everything with a CSP channel. But there's places where that's useful in 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 observable, if that's about to wash over us, the one after it is CSPs, so I wanna be aware of those things and understand how all these tools weave together.

By the end of this will be we're working through some rather challenging exercises trying to push our brains Into thinking way beyond just a simple callback. So that's where we're going with this workshop. If things seem too simple at the beginning, I promise you by the end they'll be plenty to be digging your teeth into.

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