EXPLAIN

he solution, a Promise is created and assigned to a variable. The Promise encapsulates
an Ajax call to a server application. Instead of assigning a function name to the
XMLHttpRequest’s onload event handler, the function is defined within the Promise, so
it has access to the resolve() and reject() functions, passed as parameters to the
Promise.

If the Ajax request is successful, the resolve() Promise function is called; otherwise,
the reject() function is called.
Once the Promise has been defined, it’s invoked by chaining the Promise’s then()
function call to the variable.

The first parameter to then() is the function that handles
a successful event; the second is a function handling an unsuccessful event.

There is no testing for HTTP status or errors. Instead, an ES 6 promise is used with the
HTTP request, with a status of 200 resolving the promise, sending the HTTP response
to the resolving function, and anything else rejecting the promise, with HTTP status
Text sent to the function.
The E6 Promise allows us to assign handlers to the two possible states of a pending
request: resolved or rejected.

The Promise, and the contained HTTP request, is invoked
with then(), with two parameters: the resolving function, and the rejecting function.
In the earlier incarnations of Node, the developers originally intended to use the concept
of a promise to provide asynchronous access, rather than the last argument callback that
exists today.

I believe this was a good decision, though many folks disagreed with it. I
feel the callback is more intuitively obvious solution, but those that disagree state that
the callback concept fails in more complex situations, where nested callbacks cause
additional complexity.

The interest in promises persisted and now their implementation is being incorporated
into existing and future versions of JavaScript.