Please take a look at (& star plz) this article’s companion Github project, Escape From Callback Mountain
The subjects I’m addressing have been explored by many - and rejected by others. I believe the reason for the divide is
Google Results Roulette& developers blindly trusting results. Bad/outdated examples lead to broad suspicions of terms like:
Let me start with a confession: I’m guilty of writing the same anti-patterns I criticize below, as I’m sure many JS developers are as well. Nothing I’ve laid out is meant to be personal or even directed at the original authors. I’m merely doing a code review on common patterns - I hope to pass along an understanding of my priorities & critical thinking processes.
Hopefully you will be able to spot the warning signs of bad Promises after groking this project.
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:
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
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
done are not necessary.
Bottom line: the
deferred pattern is a painful anti-pattern - it improves virtually nothing over the typical callback approach.
One more thing, my work likely has bugs or quality issues - please file an issue here - always appreciated!