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.
[00:00:18] 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.
[00:00:42] 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.
[00:01:06] 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.
[00:02:02] 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.