This course has been updated! We now recommend you take the JavaScript: The Hard Parts, v2 course.

Check out a free preview of the full JavaScript: The Hard Parts course:
The "Introducing More Browser APIs" Lesson is part of the full, JavaScript: The Hard Parts course featured in this preview video. Here's what you'd learn in this lesson:

After reviewing additional browser APIs that do not stop JavaScript from executing such as Ajax, user interactions, reading and writing to a file system or database, Will takes questions from students.

Get Unlimited Access Now

Transcript from the "Introducing More Browser APIs" Lesson

>> Will Sentance: This time you spend pairing through the challenges, and for our online viewers the time you spend hopefully pairing, but maybe soloing through the challenges is the real valuable stuff. Not so much what we do here. So, nevertheless though, right or wrongly we are going to do some more stuff here.

[00:00:17] Rightly or wrongly,. So, you're already there encountering in those challenges more than just a timer built in browser feature, built in browser API. And that the browser API they're becoming more than just a timer. Which other ones were we encountering? Andrea?
>> Andrea: Sorry, I'm [INAUDIBLE]
>> Will Sentance: It's ajax functionality, right?

[00:00:42] This
>> Will Sentance: Well, here you go. There are many things where waiting would block our thread. We're waiting for something, here we were waiting for a timer to complete, but there's other things. And therefore we use browser functionality, built in browser functionality interfaces with those functions instead. So, things we could wait for, a timer to finish running, new information from a server, an indication that a portion of the page has loaded, user interactions, waiting for users to click on something.

[00:01:18] Writing or reading to a file system in note when you write to your computer or writing/reading to a database in note. All of these are thing we have to wait for, and we got a functionality we can't wait in the main thread. So what we do, for each of these, we have a web browser feature that we can spin up in the background, where we can have a reference of the functionality that we want to call only when that background feature completes.

[00:01:47] And then parse that functionality back to the main call stack. Okay, I wanna add a few bonus things in relation to what our wonderful online audience asked. They said hold on, what if,
>> Will Sentance: When I call, when I store printHello, or reference printHello, when I use set time out, what if my block for one second.

[00:02:11] Maybe I call a function recursively, and my core stack's getting fuller and fuller. Will my printHello ever be invoked? Will it ever be added to the call stack? What do we think? If I were to call a function, maybe block for one second and inside call a block for one second and inside, basically it's recursively call a function until it's filling up the call stack until it hits stack overflow, and there's no more space to fill up any higher.

[00:02:37] Will I ever actually get a chance to push printHello to the call stack. What do you think Katie?
>> Katie: No.
>> Will Sentance: I won't. So will I ever see console log hello? I'll never see it. If I were to run for block one second, three, four, five times here, even if my time is finished, I will not insert My printHello function on to my call stack, until my call stack's empty which include my global execution context finishing all of it's code to be run.

[00:03:06] Let's be really clear on that, it includes me finishing all of my global code. If I had block for one second running ten times, all of those would run before my printHello ever got out of back to the call stack. These are a few of the questions that came from online, although it's good questions, okay.

[00:03:23] One final thing, we parse reference to printHello, not the actual copy of the function. We're actually copying the function into the web API, just a reference to it, just where it is stored in JavaScript's memory. Okay, so we wanna add to that. There are many thing we can end up waiting for, here we're waiting for a time up but what about all these other things?

[00:03:42] Well, let's see one of them before we go back to the challenges. So some of our API, some of our built in features of the browser, they actually speak to somewhere else outside of the browser like a server. Therefore they actually come back with data, the design of the web browser API.

[00:04:03] Let me be really clear one more time. Web browser API's are not, Mohammed, are not the API that you're speaking to for Bands in Town. That your JavaScript speaks to the web browser API for speaking to the band's in town API on someone else's computer. So what other browser APIs do we have?

[00:04:28] Well, we have one called XHR HTTP request. Which is this special one that allows you to speak to an API like Bands in Town. So this web browser, Chrome's built-in API, a functionality feature of the browser, is there to let us speak to the network. JavaScript cannot speak to the Internet.

[00:04:52] It speaks to the Internet by speaking to the web browser features. One of which is timer, another of which is XHR HTTP requests. A little special feature that can speak to the Internet. Can speak to Twitter's API. Can speak to Bands and Towns API. We're gonna see that one in action here, we're gonna walk through this code just the same way we did.

[00:05:15] By the way, that one is designed to be able to receive data and make sure the function that gets passed back into JavaScript land is already pre-bundled with the return data from the Bands in Town API. We're gonna walk through this one in full. Yeah, Mark go ahead.

>> Mark: Just a question on the setTimeout stuff.
>> Will Sentance: Okay, go for it.
>> Mark: Okay, well, what happens if the setTimeout is inside a function, does that function sit on the call stack until the timer runs, or does it get popped out immediately?
>> Will Sentance: Wherever setTimeout's declared or executed, if setTimeout is being executed inside a function, well that function when it gets called will inside it create an execution context where it'll then call set timeout.

[00:06:00] Which will then speak to the web browser land, instantly complete, go back into the function in which it's being called execution context, which will then run in JavaScript complete whatever. And then only then we're gonna call back function that was parsed to set timer out be finally parsed back to the call stack.

[00:06:19] So, it doesn't make any difference where you call setTimeout, if you call it inside a function fine, it's still speaking to our web browser APIs, okay, all right. I wanna look at that pairing as well to see if there is anything I can add. So, we're now going to use a different API, a different web browser API.

[00:06:43] This one is for interacting with other computers on the network, other servers, other APIs. This one is for speaking outside of our, not just JavaScript, but outside of our whole computer. We're gonna go through it line by line and see it play out in action. This is our final function for asynchronous JavaScript.