Kyle introduces concurrency as two higher-level tasks happening within the same timeframe. He illustrates these higher-level tasks or macro-tasks might be composed of many micro-tasks. As each micro-task is initiated, it queues up behind any other existing tasks and is executed in order.
- That brings us to this idea of concurrency. What does concurrency mean? A lot of people would think concurrent means two things happening at the same time. Again, that's one of those things if you squint at it you might say yeah, okay, maybe they're kind of like the same but there's an important nuanced difference here. And by the way, if somebody wants to object to my particular usage of the words there's actually lots of different meanings for these words and it's hard to nail down one particular thing so I'm trying to be as consistent within my own usage of these things but there's actually, if you go and read Wikipedia pages or other texts on it, you'll find a whole range of different opinions on these things but my way of explaining to you what concurrency is rather than saying with parallels and two things are happening at the exact same instant, I would describe concurrency as two higher level tasks happening within the same time frame.
So rather than an instant, we're going to look at a time frame and we're going to say within this time frame, two higher level operations are going to occur. To understand the notion of higher level items or higher level operations occurring, we also have to understand that higher level or what I might call like macro-level tasks can be broken up or thought of as being broken up into micro-level tasks. So here's a way to visualize a macro-level and the micro-level and how these things might go together. So the left hand side we have this yellow orange tasks, or macro-level tasks, which is broken up into those individual numbers, one, two, three, four, which would be micro-level tasks, these are my made up terms, these aren't official terms, but macro-level and micro-level tasks.
And on the right hand side we have another macro-level task represented by that blue green color, and it's broken up into three pieces, one, two, three. Now for the easiness of math, I'm going to pretend and assume that each one of these micro-level tasks takes one full second to complete. So this overall system, to do all of the tasks, it's going to take seven seconds, does everybody agree with that? 'Cause it's a single threaded system, nothing can happen at exactly the same moment, so those one second micro-level tasks are going to have to be scheduled in some way that all seven of them finish and that's going to take seven seconds.
And if you ever had an animation on your page have jitter in it, you know why that happened? Because something contended on the UI thread. At that moment, your CSS engine was trying to, or your style, your layout engine was trying to repaint the page, it's 60 frames a second way that it's repainting your page, it tried to do that but at that exact moment something else was running. So it had to wait an extra moment and that's what created that jitter. Single threading. So, if we have these higher level macro-level tasks that we want to happen concurrently, I want the yellow and the blue to happen at the same time.
Why? Well, let's imagine they don't. One way of scheduling this system, one way of scheduling this program, is to do all of the yellow first, and then all of the blue. What would that look like on our page? Ignoring the one second thing for a moment, what it would look like on our page is that it would look like I clicked a button to make an Ajax request, and while that was happening I tried to scroll my page but everything was completely frozen while that happened, and then after it finished it sort of jumped back and caught up.
We actually have precedent for that, it's called synchronous XHR, synchronous Ajax. One of the worst evils perpetrated upon the web platforms, a terrible idea. There are people out there that are crying and literally complaining on standards list saying how dare you take away my synchronous XHR, it's been deprecated and removed from the web platform, 'cause it's a really bad idea. It's a terrible idea to schedule it that way isn't it, because even though the overall system would still take seven seconds, that particular choice of scheduling those micro-level tasks would feel terribly inefficient, does everybody agree with that? Just from a user experience perspective.
If on the other hand we chose to interleave these things together, where one thing might be blocking so we can do something else while one thing is blocking before it can move on to the next thing, if we chose to schedule those things in an interleaved fashion, the overall system might still in fact take seven seconds, but the perception of the performance is that things are going to be happening in parallel. Really more importantly we should be saying those things are happening concurrently. The Ajax request and response is happening concurrently with the repainting even though at any given instant only one of those micro-level tasks is occurring.
But there's an awful lot of coordination necessary. Sometimes it's the coordination of when things happen but oftentimes it's the coordination of responses to things happening. 'cause not always a very serial, I do this and then when that's finished do this, and then when that's finished do that, oftentimes it's much more complex like hey, go do these three things in parallel and then when at least two of them have finished you can move on and do this other thing, and then when that third one comes along, you can branch out here and do this other thing and before long it's just crazy complex tree of different states of things that could happen and it's that complexity that we have to manage in our programs.
It's that complexity that begs for us to have better patterns for concurrency management. That's what asynchronous programming is. Managing our concurrency. So that's a motivation for you from a philosophical and conceptual basis, a motivation for why we go to the lengths that we do to try to write the programs that we do. Everything that I'm going to show you in this workshop is something that could fundamentally be done with nothing but the callback.
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