Promises and the Deferred Antipattern

Before ES6 came out, there were dozens of common userland promise implementations. Many used some equivalent of the Deferred pattern. The deferred pattern means that your promise isn’t strictly associated with any async operation. A deferred object is simply an object with `resolve()` and `reject()` methods.

There are two key differences between the deferred pattern and modern ES6 promises:

For example, below is how you can implement a Deferred using ES6 promises.

Since ES6 promises were released, the Deferred pattern has largely vanished from JavaScript development. I think the Bluebird docs’ rant against Deferred had something to do with it. So what is actually wrong with the Deferred pattern?

The answer is error handling. For example, in the above code, what happens if an error causes the `setTimeout()` to never be called? The promise will be stuck in the pending state forever.

ES6 promises, on the other hand, treat synchronous errors in the executor function as a promise rejection.

Things can get even more complicated for the Deferred pattern when you pass a Deferred into multiple functions. Even if you use try/catch to make sure you reject the Deferred if a synchronous error occurs, things get murky when the Deferred is used in different functions. Should you reject the Deferred if there’s an error in a logging function?

Because ES6 promises have an associated executor function, they encapsulate all the logic that goes into determining whether the promise succeeded or failed. The users of your code don’t have to guess if or when they’re responsible for resolving or rejecting a deferred.

Remember, as a consumer of an ES6-promise-based API, you are purely reactive to the promise. You have no way of affecting the promise’s state.