Native Promises

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kyle: What is a promise? There are a multitude of different ways, several different ways that promises are explained and I will choose two or three of those explanations here by way of metaphor and illustration. Again, because it's more important to me that you understand the concept behind promises first, before understanding the API.

[00:00:24]
It's the reverse of the way most of this stuff is typically taught. But I want you to understand why promises are so important. Because they're not perfect. And when there is some frustration with the promise, or something that's weird, or there's some gotcha, there are gotchas there. And when there's some gotcha down the road and you're frustrated and you find yourself.

[00:00:44]
Here's a clue. There's is such a thing as promises hell. If there's a call back sell, there's a promise to sell. When you find yourself stuck in promises hell in your cursing at them. I don't want you to turn around and say, well I just get rid of problems.

[00:00:57]
Need to understand why they're more important, than just the usage of their API. If I could change it, there are some things I would change about the API. But I wouldn't change the fact that they're there. They are one of the most important advances that we've made in codifying reasonable asynchronous coding patterns.

[00:01:16]
So, first let me give you a scenario around promises. It's silly, where it's early here together and I want to make sure that we're all kind of awake. I see people sipping on coffee and so have more coffee, cuz your brains are gonna have to fire on all cylinders to get stuff today.

[00:01:33]
But here's a silly metaphor to explain to you. I walk up to the counter at my favorite fast food restaurant, and I order a cheeseburger. So I asked the lady, I'd like a cheeseburger and she says, that will be a $39. And so I hand her the money, give her the $39.

[00:01:51]
So I have begun the transaction by ordering and giving some money for something. What am I expecting in return of this transaction? I'm expecting a cheeseburger. But oftentimes, I'm not handed a cheeseburger immediately. What instead am I given? A receipt, and importantly on that receipt it has an order number on it, right?

[00:02:10]
My order says, order number 317. So I take that receipt, and I look at my order number, and that order number has become a placeholder for my future cheeseburger. It is an IOU. It is a promise for a future cheeseburger. They owe me a cheeseburger because I have given the money, I've started a transaction.

[00:02:31]
Now, I don't have the cheeseburger yet, I can't bite into it, but that doesn't mean I can't begin to think about and reason about and dream about my future cheeseburger. I can begin to think about it in my mouth can begin to salivate and I can be in and have cheeseburgers dancing in my head about how amazing this cheeseburger is gonna be, I'm famished, I can't wait to eat it.

[00:02:53]
I have something in my hand that allows me to begin to reason about this cheeseburger, even though I don't yet have it. And then those magical words, order 317. And I walk back up to the counter, receipt in hand, order 317 printed on it. And I hand her my receipt, and what do I now get in return?

[00:03:15]
I now am exchanging that promise for the value for the value itself. This is a silly metaphor, but a metaphor nonetheless for what is happening with promises. Promises are a quantification of the idea that we need a place holder to eliminate time is the concern wrapped around the value.

[00:03:38]
We need a container around it. In programming speak, we call that a future value. It's a value that will eventually at some unspecified point become fulfilled. But in the meantime, we still need to be able to reason about it exactly the same way. Because we don't want to sit around waiting and wondering and having all these forks of different logic.

[00:03:58]
That's the complexity that makes our code. Hard to understand, hard to maintain, hard to be bug free. So the promise becomes a container that wraps around a value. If that promises come to us primarily by way and they're not original to JavaScript. But they come to us primarily by way of a language called E.

[00:04:18]
One of the members of the TC 39 Committee, Mark Miller. Is the creator of the E programming language, and in E they have these things called futures, and in E a future is literally replaced by it's value, it's literally exchanged by its value but you can perform the operations that you would normally do against that value directly, transparently.

[00:04:42]
Even though the value isn't physically there yet, you can begin to compose it, you can begin to perform operations on. We can get quite the same thing but he said you know what, this is really powerful and we should bring something to JavaScript that allows people to reason about values it ignorance of the timing.

[00:05:02]
Values are the important thing and composing values is the important thing. If it sounds like it's kind of related to functional programming, that's cuz it is. Not to throwback in those terms but promises, not their API but their mechanism, they're basically a monad. They're a functional programming concept.

[00:05:24]
The API is not quite as clean as a functional programmer would like and there have been experiments to create other versions that are more functionally sound, but the principle still the same. So if it sounds functional, it's because it is. So that's one way of thinking about a promise is that it's a future value.

[00:05:44]
Another way of thinking about a promise is that it an uninverts the paradigm that we're traditionally used to interacting with some other mechanism that's going to be asynchronous in nature. When I call some utility and I know that utility's not going to finish now, it's going to finish at some later point.

[00:06:05]
When I call that utility. How do I wait around to hear that? I have to give it a call back. I have to pass a call back in and you remember I said, that's inversion of control. When I wrap up the second half of my program in a callback and pass it to someone else, I give them the continuation control.

[00:06:22]
And I've inverted the control that I have. But what if we could un-invert that paradigm? If we could, un-inverter rather not inverted in the first place? Rather than passing a call back to a utility, what if we could say something like, I'm gonna call some function and I know it might take a while for it to finish.

[00:06:40]
I want you to return to me, when I call utility, I want you to give me back something. I want you to give me an event listener. An event listener that I can subscribe to a completion event. So I'll listen for the completion of events and you just fire that event whenever you're good and ready, and I'll be notified through this event listener that you've finished your work and I'll know it's time to move on.

[00:07:02]
In fact, in addition to being a completion of that, I can also listen to an error event. If you had some errand to notify me or other things that you want to notify me about, I could simply receiving that listener back from you and I know that's a tried and true patterns to receive something and listen to it.

[00:07:21]
Listen subscribe to events on it.