Promises for Five-Year-Olds

This is a work in progress …

I’m happily going through the Grow with Google Challenge Scholarship: Mobile Web course at Udacity. We use javascript promises throughout which I kinda sorta basically understood the basic concept of. I didn’t completely get it but I knew we’d cover it later and everyone in the forums raved about Udacity’s standalone JavaScript Promises course so I planned on taking that after finishing Mobile Web. I wasn’t worried. I understood the structure just enough to put things together and pass the quizzes (eventually) by basing my answers on examples we were given.

I got the How (they worked structurally) but not the What (they were doing) or the Why (would I use them versus callbacks and/or Event Listeners).

I got to the Promises part of Mobile Web and it still didn’t really make sense to me. So I stepped out and started the JavaScript Promises course. That was great for a few minutes then I was lost again. I can’t tell you how many times in both courses I’d said, “Wait, wait … what?!”

This isn’t a criticism of those courses and sections. My learning style is just incompatible with certain teaching styles. I don’t do well when people say things like, “A promise is a promise that returns a promise—get it?”

No. No sir or ma’am, I don’t.

I posted a question in the forums, “ELI5 How Promises Work” and gave a couple examples of how I thought they worked based on the only thing I really knew about them – they were an ES6 replacement for callbacks … right?

I didn’t wait for answers because I was scared I’d get buried under other terminology and crap that meant nothing to me and would only confuse me more. I grabbed my Google Search box by the throat like Jacob wrestling with God and shouted, “I’m not letting go until you explain promises to me!”

The MDN documentation had me for just a moment or two as well but also lost me.

For the life of me, I couldn’t understand how Promises were related to Callbacks when (I thought) one was replacing the other and it seems to me callbacks were doing all the work anyway. And … eventListeners, right?

The ridiculously awesome Jake Archibald wrote a legendary thingy on Promises that finally started me down the road to understanding. First of all, I realized callbacks aren’t asynchronous … they’re merely blocking, meaning … well, I love Jake’s explanation (which I’ve paraphrased a wee bit):

Sneezing is a blocking function. All current activity must be suspended for the duration of the sneeze. You don’t want to write code that’s sneezy.

That made perfect sense to me. Callbacks aren’t asynchronous … nothing is happening and I’ll do other stuff while it’s happening and when it’s done it will let me know … everything stops while I do this thing and when I’m done doing this thing everything starts up again. Got it.

Jake also said,

“Promises are a bit like eventListeners except … we’re less interested in the exact time something becomes available than reacting to the outcome.”

Okay. That makes sense. Jake also gave a couple examples that, at first, smacked me into “Wait, what?” land again but I took a deep breath and re-read it … and felt I had a loose grasp on it all. I’ve been there before, though, and those cookies of understanding can crumble and fall through your grasp right before your eyes.

Sadly, Jake soon lost me.

As it turns out, Promises are pretty freakin’ easy … until people try explaining them. Eventually, I found two resources that changed all that. The two most valuable things I dug up:

Don’t just read the chosen answers at each. I read through all the comments and answers and replies and they are both a treasure trove.

Even just the titles made me feel much better about my confusion.

Aviv Cohn, the author of Aren’t Promises Just Callbacks? gave this ridiculously short and simple of a callback in his question and all of a sudden I finally understood callbacks so I made some real progress even before reading the replies! Cohn then explains promises in his own words,

“A Promise is an object that represents a value which might not yet exist [emphasis mine]. You can set callbacks on it, which will be invoked when the value is ready to be read.”

That sentence immediately made sweet love to things Jake had said and gave birth to some more understanding on my part. Cohn then gave the promise version of his callback code and concluded by asking,

Is there actually a real difference? The difference seems to be purely syntactical.

The first response started to beat the crap out of me with,

“Yes: callbacks are just [insert crap I couldn’t understand]. Promises are [more crap I didn’t understand] … a composable mechanism to chain operations on values.” [emphasis mine]

Oh. Okay. I don’t know what “composable” means (more on that later) but the rest of the bit in italics made more stuff click into place. Another answer blessed me with,

It is fair to say promises are just syntactic sugar. Everything you can do with promises you can do with callbacks … The deep reason why promises are often better is that they’re more composeable, which roughly means that combining multiple promises “just works,” while combining multiple callbacks often doesn’t.

First of all, thank you for defining “composeable.” Second, this person then goes on to drop a whole bunch of other magical wisdom explaining the difference and how they work and why — in freaking English — including working with values and errors and this:

For the example you gave of a single callback versus a single promise, it’s true there’s no significant difference. It’s when you have a zillion callbacks versus a zillion promises that the promise-based code tends to look much nicer.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s