Check out a free preview of the full JavaScript: The Hard Parts, v2 course

The "Web API Rules" Lesson is part of the full, JavaScript: The Hard Parts, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Will fields questions from the audience about how the function that is used by the "facade functions" keep state, and how the call stack works when asynchronicity is introduced. These questions are used to preface the point that there needs to be clearly defined rules for how this functionality works.


Transcript from the "Web API Rules" Lesson

>> Will Sentance: Go ahead Mark.
>> Mark: So, as far as JavaScript is concerned, the function is done. So, that it's headed off for what we're talking about-
>> Will Sentance: Which function?
>> Mark: Print, I'm sorry, set time out.
>> Will Sentance: Set time out, yes. Or after our facade, our function that triggers stuff in the web browser, yeah, yeah.

>> Mark: The web browser then is directly affecting the stack at a later date- [SOUND] In some-
>> Will Sentance: That seems insane, right?
>> Mark: Yeah, that seems strange and what if the stack has got stuff in it?
>> Will Sentance: And so Marty is saying all of the call stack, what if we're running a function, does this- This function is only just rock up back in JavaScript?

That can't be right. Yeah, Braden.
>> Braydon: What about the zero millisecond example?
>> Braydon: Where did that one-
>> Will Sentance: Yeah, hold on. What about zero milliseconds? Why did the function not just come out into here and then come straight back home and run? Great question Braden, Jason?
>> Braydon: Excuse me.

The printHello function, when we transfer it, is the set time and I don't remember the implementation, is set timeout memorized so the bits that make up printHello, are they stored in we'll say it's the V8 execution context?
>> Will Sentance: So here we're hinting at something around. Hold on, does that printHello function get to hold onto any state around it?

Suppose it needs to use some other data around it, does that data get held onto? Well, where do you think that data gets held onto, people? In the?
>> Braydon: Backpack.
>> Will Sentance: In the backpack, exactly. Spreading, spreading.
>> Braydon: The note or-
>> Will Sentance: That thing stays in JavaScript, this is a reference back to where it's stored in JavaScript.

Yeah, absolutely. Yeah, yeah, the printHello function is not sort of copied into the web browser. It's a link back to where it's originally saved, including maybe all surrounding data as well. All right people. So, clearly, we have a problem here where we need to have some sort of rules for when this extraordinary other world is allowing this function back into JavaScript.

Braden hinted at this, Mark hinted at this. What if I've got other code on the stack here? By the way, what if I've got maybe a million console logs? When is this function allowed back in? Talk about unpredictable language, any time maybe? It turns out given we're interacting with a world outside of JavaScript now, we're gonna need some really, really strict rules.

And they are really strict. But it makes our code super predictable. We fundamentally know how it's gonna behave if we know these core rules. So we're gonna see this code here. We've got a function printHello, a function blockFor1Sec. A block thread for one second. How's it gonna do that because any slow task in JavaScript, it'll always throw it out to the web browser feature.

If we want to speak to the Internet, we're gonna do it in the background of the web browser. If we wanna do a timer, we're gonna do it in the background of the web browser so we don't block any further code in our single threaded language from running.

So how could we actually block JavaScript from running code for like a- have anyone does a task that it ends up blocking code from running? Yeah, Peter, go ahead.
>> Peter: Just run a for loop.
>> Will Sentance: For loop, Jason, you're gonna say the same thing?
>> Peter: Yeah, for loop, timer, something to occupy.

>> Will Sentance: Well, not a timer, cuz a timer's gonna happen down here. So, a for loop is exactly right as you say as well, Jason. It's gonna block the thread for one second, so maybe like a for loop adding I don't know, I need to find this out. Maybe adding like three million elements to an array, that's gonna take maybe about a second.

I'm not gonna write the code out here but just know that that's in that kind of black box function there. If we were to run it, it's gonna sit on the call stack doing- because you can't do one long task in JavaScript, but you can do many tiny short tasks.

And that's how we can block it. Then we're gonna be able to set timeout, we're already by the way, not unfamiliar with that with Braden zero millisecond wait. Then we're gonna call our block for one second. And then we're gonna call first. Now I assume, of course, the printHello is gonna run immediately at zero milliseconds.

Mm-hm, we're gonna need to have some pretty fundamental rules about how our code is going to run

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now