The Hard Parts of Asynchronous JavaScript

Asynchronous Web Browser APIs Q&A

Will Sentance

Will Sentance

The Hard Parts of Asynchronous JavaScript

Check out a free preview of the full The Hard Parts of Asynchronous JavaScript course

The "Asynchronous Web Browser APIs Q&A" Lesson is part of the full, The Hard Parts of Asynchronous JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

Through answering a question from a student about executing a function on a call stack while waiting for a response on an asynchronous function, Will introduces the need for rules when JavaScript interacts with Browser APIs.


Transcript from the "Asynchronous Web Browser APIs Q&A" Lesson

>> Will Sentance: But let's have thumb. You lost me, I'm clear. I have clarifications. Everybody thumbs out, I'm proud. Michelle has one, Mike has one. Mike, let's come to you first.
>> Mike: I'm just wondering how to recruit if you have layers, if you have a set time out function called that requires some more time.

>> Will Sentance: Okay, so your saying if inside my printHello I would defer further functionality. So call another function, which isn't a real function, a facade for web browser feature. Yeah, okay, let's come to that. Michelle.
>> Michelle: My question is what if I'm actively executing something on the call stack?

>> Will Sentance: Excellent, where does that go? Exacly, spot on. Suppose I have like 10,000 console logs. When is the function allowed back in? Just as soon as ready? After five of those console logs, after a few of them, what if I have a function as you say sitting on the call stack for maybe 300 milliseconds?

Or even 1000 milliseconds? When's the printHello allowed back on? It's gonna just come in randomly? Maybe. What a language design that would be. Let's just make sure we know which are our facade functions. We've got set time out. When I say facade, I mean it's a facade, it's a front.

It looks like a JavaScript function, it is not. It looks like it's gonna create an execution context, it does not, not in any way meaningful to us. Instead it just spins up background work. It's facade, it's a front. It's like those west world, God, those west world people with the face, who watches the Westworld show?

You know that bit where the faces open up my God, fucking hate that. I literally I watched the first two episodes and the first episode of the season, with my fingers like this the whole way through incase anytime I saw one of those people incase their faces opened up.

And it happened. I saw a bit of it, and I haven't watched it since. I don't like this show anymore. I don't want to see the faces opening up, but this is what it's like. It's like a facade. For those of you who have not seen Westworld, it's about pretend versions of people or maybe not.

Maybe they're as real as us. But they were originally mechanically created, meaning behind the skin was mechanical stuff. And we all know that humans find that very, very creepy. Well, that's what setTimeout's like. It's a facade for functionality outside of itself. It's not real, it's not pure JavaScript.

It's pretend. There you go. I hate analogies, that's why I hate analogies. Good, so we're interacting with a world outside of JavaScript now. We need rules. We need strict rules for how we're gonna interact with it. So we're gonna see this code here in order to identify a bunch of scenarios that are gonna indicate what our rules must be.

So here we go, line by line we're gonna walk through our code. And then by the way we're gonna get into pair programming. And then we're gonna see a brand new solution that everybody loves that does not use this model.

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