Now that we've seen examples of callback and event-based asynchronous programming in
client-side and server-side JavaScript environments, we can introduce Promises, a core
language feature designed to simplify asynchronous programming.
A Promise is an object that represents the result of an asynchronous computation. That
result may or may not be ready yet, and the Promise API is intentionally vague about
this: there is no way to synchronously get the value of a Promise; you can only ask the
Promise to call a callback function when the value is ready. If you are defining an
asynchronous API like the getText() function in the previous section, but want to make it
Promise-based, omit the callback argument, and instead return a Promise object. The
caller can then register one or more callbacks on this Promise object, and they will be
invoked when the asynchronous computation is done.
So, at the simplest level, Promises are just a different way of working with callbacks.
However, there are practical benefits to using them. One real problem with callback-based
asynchronous programming is that it is common to end up with callbacks inside callbacks
inside callbacks, with lines of code so highly indented that it is difficult to read.
Promises allow this kind of nested callback to be re-expressed as a more linear Promise
chain that tends to be easier to read and easier to reason about.
Another problem with callbacks is that they can make handling errors difficult. If an
asynchronous function (or an asynchronously invoked callback) throws an exception, there
is no way for that exception to propagate back to the initiator of the asynchronous
operation. This is a fundamental fact about asynchronous programming: it breaks exception
handling. The alternative is to meticulously track and propagate errors with callback
arguments and return values, but this is tedious and difficult to get right. Promises
help here by standardizing a way to handle errors and providing a way for errors to
propagate correctly through a chain of promises.
Note that Promises represent the future results of single asynchronous computations. They
cannot be used to represent repeated asynchronous computations, however. Later in this
chapter, we'll write a Promise-based alternative to the setTimeout() function, for
example. But we can't use Promises to replace setInterval() because that function invokes
a callback function repeatedly, which is something that Promises are just not designed to
do. Similarly, we could use a Promise instead of the "load" event handler of an
XMLHttpRequest object, since that callback is only ever called once. But we typically
would not use a Promise in place of a "click" event handler of an HTML button object,
since we normally want to allow the user to click a button multiple times.