This story is unavailable.

Yep. There was some fairly famous pressure from FP folks to try and give Promises a more standardized type behavior, which was mostly deflected because of a strong desire for Promises/A+ to conform to, and not break, previous similar patterns and Promises/A+ implementations (jQuery-v2.Deferred, Bluebird’s Promises, for example). That pushback, in fact, was part of the inspiration for Fantasy Land.

In JS, there are now a bunch of great, Fantasy-Land compliant algebraic implementations: Future, Fluture, and Task, and so on. I think it’s still interesting to work with Promises and to examine how they can be made to conform to some of those requirements, exposing common behaviors. Which is why I generally use them in examples (since people are familiar with Promises, but not necessarily algebraic types: myself included!) But in production/real coding, it’s probably best to stick to well-tested/optimized types that explicitly try to work to FL’s spec instead of using Promises if that’s the sort of coding you want to do.

Like what you read? Give Drew Tipson a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.