The Hard Parts of Asynchronous JavaScript

Wrapping Up Web Browser APIs

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 "Wrapping Up Web Browser APIs" 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:

Will reinforces the knowledge of how deferred functionality in Browser APIs works.


Transcript from the "Wrapping Up Web Browser APIs" Lesson

>> Will Sentance: Before we do that, what are the problems of this? No problems. There's a beautiful intuitive approach once we understand under the hood how it's working. Response data, it's only available in the call-back function. We don't see this here, we're gonna see it in a moment. Any data that comes back from our web browser features work.

For example, I go and get some tweets from Twitter. They're gonna be parsed as the argument to the function that was set up to run on completion. That can get pretty complex, because the data is only gonna be available inside of here. That can get pretty messy. And maybe it feels odd to think that parsing a function into another function, only for it to run much later.

Maybe it feels odd? It definitely feels odd. When I see that, setTimeout(printHello,0), everything tells me that I must be running printHello somehow inside setTimeout. Everything tells me that. Especially if it says zero milliseconds. And yet, I am absolutely not. I am passing a function definition in, only for it to be invoked beyond my control.

Much later in application. That losing control of our execution and defining something, printHello separately that's gonna [INAUDIBLE] Well, not arbitrarily, but beyond that control going to be called? Late. When we write code we kind of think of it somewhat at least of being, I'm taking control of the structure of my code.

But instead I'm leaving a whole piece to be run beyond my control later on. That is a weird feeling. I'll say this, once you understand under the hood how it's working. it's actually not too bad. If you don't understand under the hood how it's working, it's horrible. But if you understand under the hood how it's working, you know that this is a pretend function in JavaScript.

It's a facade. For functionality in the background. You know this function is gonna be passed into a queue and then allowed back into the JavaScript, yes, beyond your control, but that's the whole nature of asynchronous programming. You do a single thread of sending off tasks and you bring them back in automatically, ready to be used in function or their return values or their response values.

Ready to be used in functionality that you set up earlier to be called later on. You get that that the very model of asynchronous input, output architectures. You get that that's the design. But I understand it's not intuitive. Benefits, super explicit once you understand how it works under the hood.

The function you parse in is gonna be auto-triggered. From the Web browser feature's completion, back into JavaScript, and then be called when the Web browser finishes its work, or Web browser feature finishes its work.

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