10 reasons to NOT use a Promise library

reasons_to_NOT_use_promise_libraries.md

10 reasons to NOT use a Promise library

1. Promises don't solve the async code flow any better than async helper methods (like https://github.com/caolan/async)
2. makes debugging a pain when you actually care about a readable call stack. Most Promise implementations blow up your callstack and make the stack origin disappear. Async helpers (basically wrapper methods) maintains the stack and tries to keep the wrapping to a minimum. No magic.
3. error handling is obfuscated and usually introduces non-optimal code paths by needing to wrap everything in a try...catch block. Additionally, code inside a try...catch is hard to optimize for a JIT compiler (http://jsperf.com/try-catch-performance-overhead).
4. error/ failure state handling needs to be expressed explicitly, there is no convention thus enforcement to handle errors properly. This makes using promises likely to introduce issues a developer doesn't expect
5. promises implementations differ a LOT from each other, most often in the area of semantics. This makes it so that you may know one implementation, but can not use another.
6. The most-often used Promise implementations are not easy to contribute to. It isn't bug free (no software is). If you encounter one, the code is complex enough, so you'd have to wait until a more active or seasoned developer may be able to fix it.
7. tests don't benefit from promises to the point of usability, because they are hot code (changes often). The boilerplate code that is necessary to start using promises properly (with error handling and such) is too much to not pollute the actual test subject
8. in general - and more towards an opinion: you shouldn't use a helper library that you wouldn't be able to write yourself upon first glance. It might help you at first, but not in the long run.
9. they're inherently viral. If they're used in one place of the codebase you have to grok and use them in code that interacts with it.
10. Using Promises requires adoption of a mental model, which changes the way code is organized significantly. You splice code into abstractions that map to the model of Promises - the tool you're using to make your life easier - on top of the models/ patterns we are already using, like breaking up large function bodies into smaller ones, classes and modules.

It has happened several times that, after explaining this rationale to others, I was pointed to this - rather well-written - gist: https://gist.github.com/domenic/3889970, in the sense of RTFM, along with 'go read the spec and come back after'. This illustrates the point vividly that making the true promise of Promises come true does not lie in a Javascript library, but in a core JS or DOM feature (http://dom.spec.whatwg.org/#futures).

mikedeboer.