Introducing Asynchronicity

[00:00:03]
>> Will Sentance: We're going to move on to now the wonderful world of asynchronicity. Asynchronicity is going to change up this whole model. I'm gonna change it up. It's going to augment this whole model. This whole model is going to continue to exist. In fact, the reason we are going to need to augment our model, is this model is going to be fundamentally untenable in how we think about doing tasks that take a long time.

[00:00:33]
So, let's just confirm. JavaScript is single threaded, one line of code executing at a time. When I start running multiply by 2, I'm not allowed to continue on in my global code,
>> Will Sentance: To executing the next multiply by 2 at the same time. I'm not allowed to, single threaded.

[00:00:52]
But simultaneously, I'm also not allowed to move on to the next line regardless, because, until I finish multiply by 2's call, because JavaScript is synchronous. Now, all that means is I go from top to bottom. I never move on to the next line, until I've finished on the previous line.

[00:01:08]
I never, ever move on to the next line. If you see a function clue, I must return out of it. I must finish executing it before I hit the next line. Well, this implies a big problem. What if I multiply by two call where I call to a server, that was gonna take 300 milliseconds?

[00:01:27]
I'm not allowed to move on from that line to run any more JavaScript until that comes back. What if I click view more tweets, it runs JavaScript code that says, go get more tweets. It's gonna take 300 or 200 milliseconds before the tweets come back, but in the meantime, I'm clicking like on a tweet, which is gonna run more JavaScript code to turn it to pink and to increase the number of likes on that tweet in my state, to my memory.

[00:01:55]
That can't happen, I'll be sitting there clicking because I'm still busy waiting on the line saying go get more tweets. Because I've gotta wait til it returns back the tweets, right, before I can move on to my next line that says, color the heart pink, cuz I clicked the button.

[00:02:10]
This is gonna be a profound issue. What if we want to wait some time before we can actually use or own bits of code. We want to wait until our data comes back from Twitter, before we can then display and run the functionality, display that data.
>> Will Sentance: Perhaps we need to get more data from the API, or even a timer to complete, and then we wanna run some code.

[00:02:33]
We have a conundrum. A tension between wanting to delay some code running, because we're waiting for data to come back, so we wanna have the next line of code display those tweets. We wanna add the data to actually come back. But we do know to block our single thread from continuing to run code.

[00:02:50]
There's gonna be a profound conundrum. It's gonna be the essence of why we have to introduce in JavaScript a whole complementary model to our beautiful synchronous world. This, these three parts of JavaScript alone are not enough. What's particularly interesting is asynchronicity in Java, asynchronous world of Java is the interesting stuff.

[00:03:11]
I love our pure simple JavaScript engine, but everything we love about web application development is not happening in pure JavaScript. Pure JavaScript does not know how to speak to the Internet. That is not a feature of JavaScript to speak to the Internet. Instead, all those features are sitting outside of JavaScript.

[00:03:33]
They are sitting outside of JavaScript in where? What's your name, dude?
>> Alec: Alec.
>> Will Sentance: Alec, where are they sitting? Where are those features of JavaScript that are not, they're doing things like speaking to the Internet. Where are they?
>> Alec: APIs?
>> Will Sentance: Or not features of the JavaScript, sorry.

[00:03:47]
Where are the features that speak to the Internet that Java should be using? Yeah, what does that mean?
>> Alec: I don't know, restful web services and.
>> Will Sentance: Michelle, where are those features that, for example, can speak to the Internet?
>> Speaker 3: Are the in the browser [CROSSTALK]?
>> Will Sentance: They're in the browser.

[00:04:01]
The browser is a wealth of features that we in JavaScript get access to. We write JavaScript code that is essentially a facade, we're gonna see these, our facades, for a bunch of features that are not in JavaScript, but are instead in the web browser. That's what we're gonna end up spending most of our time this morning doing.

[00:04:26]
Is writing JavaScript code that interfaces API. So Alex is right. Interfaces, the I in API stands for interface. That interacts with stuff outside of JavaScript. Okay, we need a whole new bunch of features in JavaScript and outside of Javascript in order to understand how this is working. So here we go.

[00:04:50]
Here is our first solution. And I'll pre tell you that it's fundamentally untenable. But here's our first solution for how to go and do a task that is going to take a long time like speaking to Twitter and getting our tweets back. And nevertheless, be able to continue running code, but know where that data is when it comes back.

[00:05:11]
This first solution here is going to be untenable, but it is nevertheless going to be fairly intuitive, but completely untenable. All right. Line 1, and by the way, so far we're still seeing things that are very analogous to the first hard parts, but we need to get these foundations down to understand the harder pieces to come.

[00:05:36]
All right, line 1, Abdie?
>> Abdi: Well, we're declaring the display in our variable environment.
>> Will Sentance: Yeah, very nicely put, Abdie. Displays declared, excellent. Next line of code, Alec? Do the left hand side first.
>> Abdi: We're declaring data from API.
>> Will Sentance: Yeah, and what's it gonna be assigned?
>> Abdi: The fetchAndWait function.

[00:06:05]
>> Will Sentance: No, we never assign function. If we just had no paren's there, it would say well, what's fetchAndWait? And it would assign it to that, whatever it is. But JavaScript's not doing that on the right hand side. And what a paren's always telling me to do, Blessing?
>> Speaker 3: Decode a function.

[00:06:21]
>> Will Sentance: Decode. The right hand side here is a command. It is unfinished work. So be really clear with yourself in no way are we assigned. Data API has zero interest in fetchAndWait. Its only interest is in whatever gets returned from fetchAndWait, which we hope will be our tweet.

[00:06:42]
Okay, so fetchAndWait here is a made-up function, but let's just see what it does. So data from API is going to be the return of fetchAndWait to our Twitter URL. So we're hoping it's gonna return a nice tweet for us. That's what we're hoping. So let's start tracking our time passing.

[00:07:12]
We're at about one millisecond here. Let's say this thing here takes 200 milliseconds to complete.
>> Will Sentance: 200 milliseconds later,
>> Will Sentance: Finally our data comes back. Could be 300 milliseconds, could be half a second. We don't even know. In that time are we allowed to move on and run any further JavaScript code?

[00:07:43]
Absolutely not, we are not allowed to move on. We are blocked because our JavaScript thread is synchronous. There's work we're still doing on the right hand side here. We're not allowed to move on to the next line, and we wouldn't want to because the next line says, display the data of your API.

[00:07:58]
So we better have that data back if we're gonna display it. This is our solution 1. Be clear, this is not the right solution, but this is a solution. So 200 milliseconds passes, and our request to Twitter returns out, let's just say, very nicely it returns out our data, and it is the, it is the single Tweet, and it's not even coming back as an object, of course they come back as objects.

[00:08:25]
But just a Tweet high. And we're going to store high, where, Michelle?
>> Michelle: In data from API.
>> Will Sentance: In data from API. I apologize for sounding like I'm correcting all of your pronunciations. Of date to data, but I'm not. I embrace your mispronunciations. Okay. Well done all of you for corrupt, no, not corrupting.

[00:08:52]
>> Will Sentance: Good. Customizing a beautiful language. All right. Okay, good. So Data API has high, the string high stored in it. 200 milliseconds later, in that time no further JavaScript code could run. This is absolutely disastrous. Whatever, now we hit our next line which is, who haven't I called on yet?

[00:09:16]
Sonny, what's our next line of code say to do?
>> Sonny: To pass the data API to display as high.
>> Will Sentance: Right. So we pass out to recalling the display function with our argument being the value of data from API, everything in Java is we're going to evaluate it immediately, data from API here is a string high', we throw it straight in.

[00:09:39]
And we create using context to run it where in the memory, this is really clear here, in the memory data the parameter data is set to that argument high. And so we're going to log in our console. At about 201 milliseconds we're going to log high. Okay. And now finally, what line do we hit next?

[00:10:05]
Gentleman, what's your name?
>> Ben: Ben
>> Will Sentance: Ben. Sorry, Ben.
>> Ben: We're gonna log me later.
>> Will Sentance: Me later is gonna be logged at the much later time of 202 milliseconds, me later is logged.
>> Will Sentance: Raise your hand if you're a huge fan of this solution. I'm a huge fan of this.

[00:10:34]
No, I don't mind the solution. Here's why I don't mind the solution, is it is profoundly intuitive. Three goals we have, three goals we have. Be able to do tasks that take a long time, slow tasks, like getting data from Twitter. We have to be able to do that.

[00:10:50]
Otherwise, our web app is very, very boring. Our best we can make a hangman game, a very nice hangman game in the command line, but that's the best we can do. But we wanna be able to continue running our JavaScript code in the meantime. We could not do that here.

[00:11:03]
Look at this, in the meantime, Node JavaScript code was allowed to run for 200 milliseconds. When our slow task completes though we should be able to run functionality knowing the task is done and data is ready. That's the hard bit. So it turned out, every other solution we have, that's the hard bit.

[00:11:19]
In this solution, not a hard bit. This solution, it's effortless. I can see where my data is synchronously in order, in memory. I've got no issues when my display function is gonna run. It ain't gonna run literally in my single thread until I got my data back. I'm dealing only in the synchronous world here, in order, in order top to bottom.

[00:11:37]
That's why we love JavaScript single threaded model. That's the vision behind it, is it's highly predictable, and easy to work with a developer. But obviously, it's fundamentally untenable. Blocks our single JavaScript thread from running any further code while this task completes. Benefits, it's definitely easy to reason about, but it's untenable.