Async Function Exercise

[00:00:00]
>> What we're gonna do now is we're gonna together fill in the code that we already know how to do. We already know the procedure for getting this data, and weighting it, and everything. We're gonna fill in TODO 3 to fill in the body of this async function.

[00:00:17]
Okay, so we have this two to three, we have a fetchMessage (url). So, we've got our URL and we know how to fetch the resource at that URL into a response, all right? So, we're gonna work through this, you're gonna help me write out the thing that we've done like several times now, how do I capture that response?

[00:00:39]
Well, what function do we use to get stuff from the internet?
>> Fetch.
>> Fetch. So I'm gonna fetch the URL, but I have to await the fetch. And then I wanna do something with that value, so I'm going to capture it as a variable. Now yeah, we've been doing a lot of let's around here and I've been not practicing what I preach of we don't need to reassign this so we can use a const here, great.

[00:01:02]
Okay, then I need some body. [LAUGH] So how do I get the body of this response? One more time, we've done it few times now.
>> Response.json.
>> Await.
>> It's also await.
>> Await response.json, which is gonna parse that body. And then we want just the message property or the value of the message property.

[00:01:28]
So, how do I do that with my destructuring?
>> Squiggly.
>> Squigglies, yes. And I need my declaration keyword and we've been using let, but I could also use const. So in the squigglies, I'm gonna put the name of the property that I care about which is,
>> Message.

[00:01:44]
>> (message) =
>> body.
>> body, and then I want to return the message, yeah. If this works, I should be able to paste it in here. So now I should be able to call fetchMessage on this URL, and is this gonna work? No, I have to add my friend await, and my gosh, we got out the dogs we care about.

[00:02:17]
[APPLAUSE] Yeah, you see that one only took us a couple of minutes, nice. Okay, so now we've really flexed our async muscles here. We've got a few different async operations happening, fetching, parsing JSON, and we've returned all of that in an async function, which means we have an async value there, a promise that we need to await.

[00:02:40]
Excellent work y'all. Any questions so far?
>> Just to clarify.
>> Yeah.
>> When we use the function, we have to say await name function.
>> Well, we don't have to, but the thing is that similar to before when we called fetch for the first time, if we call our fetchMessage function because we declared it with async function.

[00:03:01]
If I call fetchMessage, what I get back is a promise. So we don't have to use await, but if we wanna do anything with the value, we're gonna need await. So that is the difference there. Good question. Okay, yes.
>> Since JavaScript is single threaded natively and since it has outgrown the expectations of the original designer, isn't it more performant and easier if it were multithreaded without adding the fake multithreaded of asynchronous?

[00:03:40]
>> Yes, as we said, JavaScript can only do one thing at a time, it's single threaded.
>> And we're not getting into really the computer science behind what that means exactly, and what threads are, and all that stuff, but you can go read about it. What JavaScript was originally intended to do and what it's doing now are two very different things.

[00:04:02]
And the complexity of programs that JavaScript was originally designed to run was somewhere along the lines of log this thing to the console when somebody clicks a button or something like that. It was very simple kind of functionality or maybe change this, send a submission of a form.

[00:04:23]
Now we have entire, huge, complex programs written in JavaScript where lots of different stuff is happening. And we really wish we could use all of the computers like multicore processors that didn't even exist in 1995 when we were running Netscape on our Apple whatever [LAUGH] original max, I don't remember.

[00:04:45]
And so yes, there is a big delta, a big difference between what JavaScript is doing right now and the structure of JavaScript that was created back in the day. So could there be a more efficient way to re implement JavaScript that does not have this notion of asynchronous operations that are pretending to be happening in the background where they're not really happening in the background?

[00:05:11]
And all of that comes down to this event loop thing that we don't even know what it is, we're gonna go find out about it later. Yes, theoretically, you could imagine a different version of JavaScript that has totally different features. But here we are in this universe where this is the JavaScript that we have, and this is how it works, and this is how web browsers have implemented it in what's called JavaScript engines.

[00:05:35]
So within your web browser, there is an engine running JavaScript. In Chrome, it's called V8. In Firefox, it's called Spider Monkey. And there's different implementations of JavaScript running JavaScript engines. And so you could imagine a different one that works totally differently. But here we are, we have these major web browsers, we have the major contexts in which JavaScript is run.

[00:06:03]
And we have the way that it thinks about time and the asynchronous-ness and the event loop and all that being part of it. And this is what we have to work with. And so yes, theoretically, you can imagine and there's lots of interesting discussion out there, I'm sure about all of the different ways that JavaScript could be doing things differently and more efficiently.

[00:06:24]
But, what we have is what we've got. [LAUGH] So, that's kind of a answer to a good question that yes, there are alternate universes out there probably where we're all writing way different JavaScript in some other universe somewhere.