to callback hell and back
by Adam Winick
Pleased to meet you
• Electronic musician, passionate developer, devoted father
• Sr Web Developer at Real Matters
• Current project is a realtime web app using jHipster (Angular/
SpringMVC/Node with a dash of D3) in production and currently
supporting a migration to React
• UI Designer
Why another presentation on
• This is the intro to promises I wish I had before reading all the currently
available intro to promises
• Not enough focus on the core promise concept, a library (and a library
speciﬁc API) is introduced before all the concepts are explained: except
for this article:
• Now that we have a Promise Spec, we can start writing promises lean
and native without a library speciﬁc API
What are Promises?
• As a programming concept :
A promise represents the eventual result of an asynchronous operation
• They are there to help manage complexity in the order of execution of
our functions in our apps.
• As a ECMA Speciﬁcation :
We ﬁnally have a Promise Speciﬁcation and several implementations
ES6’s native promise have adopted the Promise/A+ Spec:
In these implementations, at their core they give developers use of a
“promise” object or function with a then method whose behaviour
conforms to the Promise Speciﬁcation.
Why should we care?
• JS functions at their core are synchronous
They execute logic, return values, and throw exceptions
• Modern JS in 2015 ( Node, consuming API’s, data fetching ) is mostly asynchronous
You can’t return values if they aren’t ready.
You can’t throw exceptions, if nobody’s there to catch them.
So we use callback functions to manage the order of execution.
In complex situations this can result in “callback hell”.
• How do JS promises save me from hell ?
The point of promises is to give us back functional composition and error bubbling in the
async world. They do this by saying that your functions should return a promise(an
eventual result), which can do one of two things:
Become fulﬁlled by a value
Become rejected with an exception
We now have behaviour formally reserved for synchronous logic :
1. Flattened callbacks
2. Return values from asynchronous function
3. Throw and Catch exceptions
For a Promise to make (2) and (3) work, the asynchronous function itself
should return a Promise Object. This Promise object has two methods,
then and catch. The methods will later be called depending on the state
(fulﬂled || rejected) of the Promise Object.
The next question is: How do we convert an asynchronous function
to return a Promise Object?
Diﬀerences between callbacks and promises
1. Callbacks are functions, promises are objects
Callbacks are just blocks of code which can be run in response to events such as as timers going oﬀ or messages
being received from the server. Any function can be a callback, and every callback is a function.
Promises are objects which store information about whether or not those events have happened yet, and if they have,
what their outcome is.
2. Callbacks are passed as arguments, promises are returned
Callbacks are deﬁned independently of the functions they are called from – they are passed in as arguments. These
functions then store the callback, and call it when the event actually happens.
Promises are created inside of asynchronous functions (those which might not return a response until later), and then
returned. When an event happens, the asynchronous function will update the promise to notify the outside world.
3. Callbacks handle success and failure, promises don’t handle anything
Callbacks are generally called with information on whether an operation succeeded or failed, and must be able to
handle both scenarios.
Promises don’t handle anything by default, but success and failure handlers are attached later.
4. Callbacks can represent multiple events, promises represent at most one
Callbacks can be called multiple times by the functions they are passed to.
Promises can only represent one event – they are either successful once, or failed once