[erikpukinskis]

That’s a really insulting way to argue your point. I’ve been writing JavaScript for 15 years. Full time for probably six years, when I dropped Rails for Node and Ember.

Right now I am programming full time in a promise shop for work, so I am very familiar with that. At home I write 100% callback style and find it superior.

The worst is when you have to mix the two, which is why NPM is such a shit show, and why I think async/await will only make things worse.

If you’re willing to spend a few minutes considering an alternative perspective to your own, you might read this: http://callbackhell.com

You say promises are more readable. I do agree promises make it easier to read and write awful code with gnarled architectures. Callbacks force you to name things and separate concerns, which is helpful if your goal is to write good code. If you just want to hack layer upon layer of garbage into the system, as most employers would prefer you do, then promises will help you hold on for that ride longer. Callbacks will break down faster.

I think that’s a feature, as it alerts me to architecture problems sooner. But you may prefer less refactoring and a more additive-only programming model, in which case promises will be a useful tool for you.

[namelost]

If your coworkers are so bad, wouldn't you rather get a nice message in your console when they forget to handle an error? With callbacks, error handling is entirely on the honor system.

There may well be some situations where callbacks are tolerable, but any time you have to converse with an external synchronous resource like a filesystem, database or REST API, it's just painful. Making a new function (named or otherwise) for each line of code is not good style, in any language.