Beating a dead horse?
Promises had a rough early start, and combined with Google's results bias to favor ancient articles (5+ years old), you may get the impression nothing has changed. Perhaps you are skeptical of Bluebird since Promises are basically native now. Or maybe you are still a native Promises holdout, I understand.
Really, I was a hater: for a while my only experience with "Promishes" was with jQuery.ajax, dojo.deferred, and the dreaded Q library.
I once worked on a codebase littered with astoundingly awful uses of Promise patterns.
Example:
while(!globals.bar) { when(getBar()).then((bar) => globals.bar = bar) }Often 500+ line methods would 'block' execution until a
.then()could set a global variable.setIntervalwas sometimes in the mix, other times they threw errors. They didn't believe me when I warned many of their issues were from errors silently being eaten bysetInterval. [Wrote a 5 line proof on the spot for the "sr." coders: Complete. total. silence.] They were so convinced their issues were caused by promises, they didn't hesitate to make their problems 100x worse by hacking around Promises.
Years ago, I completely despised Promises. Thought they were an "unnatural" somehow. After much hand-wringing about async/await's lack of availability, I learned about BluebirdJS's version of Promises. It literally fixed every problem I was having after I spent 10 minutes with their docs. I'm still beginning to appreciate how versatile, readable, & scalable (modern) Promises can be.
The following notes are a rough code review of (mostly) old articles. Let me be clear, nothing I've laid out is personal or even directed at the original authors.
This is meant to help JavaScript developers identify flaws in their own Promise-based code.
CREDIT: http://callbackhell.com/
CREDIT: https://strongloop.com/strongblog/node-js-callback-hell-promises-generators/
CREDIT: https://blog.risingstack.com/node-js-async-best-practices-avoiding-callback-hell-node-js-at-scale/ This is a pretty solid article. I only have 1 concern:
CREDIT: https://github.com/kriskowal/q
The Q library is one of the most used & oldest to be associated with "Promises." Hence it suffers from aging examples and it's need to maintain backwards compatibility.
I say "associated with 'Promises'" since I feel Q is really about the deferred pattern.
It may resemble Promises, however I insist it ain't. It has far too large a surface area for all the wrong reasons. Also the naming convention inconsistently abbreviates names, making it harder to memorize the interface. Methods like when and done are simply unnecessary.
Bottom line: the deferred pattern is a painful anti-pattern - it improves virtually nothing over the typical callback approach.
Find bugs or quality issues - please file an issue here - always appreciated!
I know we wouldn't be where we are without the early work of those libraries/authors. I came upon these anti-patterns by writing my fair share of them 😞, as I'm sure many other JS developers have as well.
- Steps
- Bonus Material
