Recap

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Kyle: Let's take stock of where we've been through this workshop. There's an awful lot that we've gone over. Started at the beginning with callbacks. Looked at the disadvantages, the shortcomings of callbacks and thinking about the call back hell, it's this notion of.
>> Kyle: Inversion of control and non-local and non-sequential reasoning.

[00:00:24]
We looked at thunks, and they didn't really have any solutions to that. But thunks at least gave us a conceptual underpinning for values that are time independent. Removing time as a state complexity. Thunks led us into our discussion of promises. And promises are not only that, but they are also a solution to inversion of control because the way they're built is designed to create a trustable system and predictable system around the way callbacks are behaving.

[00:00:51]
Generators, generators are the other part of callback hell being solved, giving us a localized pauseable stack. With local stack execution and local error handling and that sort of thing. So we now have blocking sequential synchronous looking code, that under the covers is factored away, that the asynchronicity is happening.

[00:01:15]
Those are great. That's our baseline. But then we say well how are we gonna to adapt an event based programming, cuz there are lots of events that we deal with in modern complex APIs. Well, turns out observables are a great way of doing it. We looked at a lightweight version of observables that I call reactive sequences.

[00:01:32]
Finally the CSP go-routines is kind of like, if observables are just over the horizon, CSP is the thing that's coming on right behind it. So a couple years from now everybody's going to be thinking wow, why didn't I get on the CSP train earlier. So, we've come a long way, and the point that I wanna make with the slide is, there's no one item on this list that replaces all the other items on the list.

[00:01:57]
There's no silver bullet. There's no one thing. I hear this from time to time. I hear people in the reactive programming world say, why do I ever need a promise, cuz I can model everything with an observable. And I hear people in the CSP world saying, why do I ever need an observable cuz I can model everything with the stream.

[00:02:14]
I can see that to be a very immature, naive way of looking at what we're doing. So the reason for this workshop. The reason this workshop exists is to show you all of these different tools, and to have you come away with a better appreciation for where they all fit in in the bigger scheme of what we're building.

[00:02:32]
No one tool here is gonna be your solution from now on. But the collection of all these tools, is a significant jump forward, not just a little bit. But orders a magnitude jump forward for your ability to expressively show asynchronous coding in your programs.
>> Kyle: So to really hammer that point home, I built, so I don't know why I hit escape.

[00:02:57]
I built a thing a couple of weeks ago and released it, it's called A Tale of Three Lists. I'm gonna show you this demo, but let me tell you why this thing exists. Anybody ever heard of the to do MVC Project? Some of you are probably nodding your heads, you've heard of it.

[00:03:12]
What was the point of to do MVC was, everybody that has their own special framework that they're like this is the magical silver bullet. They got an opportunity to solve the exact same problem using their code. Well now you have, I don't even know how many like 30, 40, 100,000, who knows how many projects that have been submitted there.

[00:03:31]
Where everybody who has their own special unicorn framework, gets to show off the way they do it to do [INAUDIBLE] okay? But what about asynchronous programming? I decided to set out and create the to do MVC for asynchronous programming. And that's what a tale of three lists is.

[00:03:48]
It's a slightly more complex than just a fubar kinda thing. It's more complex cuz when I show you the demo, there's events firing all over the place, and pauses and stuff like that. But then I went and implemented the same demo seven different times, using seven different asynchronous patterns.

[00:04:06]
The stuff that we've gone over in this workshop, I implemented the same code base, side by side, seven different ways. And I'm open to contributions from others who may have other patterns that have relative strengths and weaknesses. But the point is we now have seven side by side code bases doing exactly the same task, but different ways with different strengths and weaknesses, as a learning tool.

[00:04:29]
And that's what I wanna get across. If you haven't heard anything else I've said, be able to go through and say I see how the promises one works, and then I come and look at the observables one, and I see places where that's much more powerful. But there'll be places where the observables have some awkwardness.

[00:04:44]
And so we can go and look at the CSP one and say, wow the CSP one is better at that than the observables one. And the take away is, find the best tools for any given part of your application and apply them maturely. So, let me show you the demo real quick.

[00:05:04]
>> Kyle: This is the repo by the way. So I'm actively open to other people submitting and improving things. But here is the demo, and this is the one using callbacks. But they all behave exactly the same, so.
>> Kyle: So what this is, is there is a producer that's producing messages every 50 milliseconds, and I have two different listeners that are sampling that stream at different speeds.

[00:05:31]
So over here I'm sampling at once every I think 900 millisecond,s or something and over here every 600 milliseconds. I don't remember what the numbers are. But I'm sampling them at different speeds and printing them into this list. In addition to them being sampled at different speeds, I'm also listening to clicks on these, and when you click on the item it adds it to your center list.

[00:05:51]
So all of these streams or firing at all these different times, and in addition if there's a duplicate it gets marked off of our list. So this is just randomly generating all these different messages that are being added to the list. Well now you're like well jeez, I'm getting too many messages.

[00:06:08]
I need to pause. So you can pause one or both of the lists. And when you pause both of the lists, now the producer who is producing that message, he stops producing. Because if he kept producing and nobody was consuming, well now you'd be wasting crazy amounts of battery power.

[00:06:28]
So, it waits for both consumers to be paused and it stops producing, and then once one of them starts consuming again, he starts sending them out every 50 milliseconds. So, the point that I'm making is if I were to pull up the CSP one for example. It's the exact same behavior here but implemented with CSP semantics.

[00:06:49]
So if we run the CSP one. If I pause both of these lists, and there's nothing happening in the app. We should be able to open up and do a profile, a JavaScript CPU profile. And we should be able to see that nothing is happening because everything has been paused.

[00:07:09]
And in CSP that's super easy, cuz if nobody is consuming then it doesn't matter how many times you try to push something out, right? So that part I got for free with the CSP implementation. Whereas with the callbacks you had to do a lot more work. But let's collect the CPU profile real quick.

[00:07:25]
And I'll just let it run for a couple of seconds as I'm talking. Nothing's happening in the background of the page, so we should expect basically an empty profile. And you'll notice that idle was the only thing that was happening.
>> Kyle: [COUGH] If you look at the delta, the difference between the callback implementation, and the CSP implementation.

[00:07:46]
It takes a whole lot more work to make that same capability happen. So this is a more sophisticated demo than most people show off asynchronicity. And the reason I wanted to do that is, it's really easy to miss the important details when you have trivial, hello world examples.

[00:08:01]
So I wanted to have something that's more sophisticated, more real world looking-ish. Maybe not quite as sophisticated as a To-Do app, but it's more real world-ish from the perspective of events and asynchronous programming.