Just how easy JavaScript, like lisp, makes it to pass around pure anonymous functions and make good use of closures (if you are willing to tolerate a few brackets). Promises had to ruin it by wrapping functions into stateful objects.
Really the best case I found against Promises comes from, believe it or not, the pro promise chapter of a book:
https://github.com/getify/You-Dont-Know-JS/blob/master/async...
I really don't understand how the author managed to view the things he described as positives.
Just the length of the chapter is a testament to how overly complex promises are. On top of bringing in a ton of jargon such as "thenable", "rejection", "fullfilment", "future value" (I think the author means you are guaranteed a nextTick whooptidoo), "uninversion of control", "revealing constructor", it admits that promises do not solve most of the issues mentioned about callbacks in the previous chapter and often makes things fail in more subtle ways.
It describes how you have to manually call things like Promise.race() to solve some of the problems hardly making things more automatic then callbacks.
He talks about "Thenable Duck Typing" saying horrifying things such as
"Given that Promises are constructed by the new Promise(..) syntax, you might think that p instanceof Promise would be an acceptable check. But unfortunately, there are a number of reasons that's not totally sufficient.
Mainly, you can receive a Promise value from another browser window (iframe, etc.), which would have its own Promise different from the one in the current window/frame, and that check would fail to identify the Promise instance.
Moreover, a library or framework may choose to vend its own Promises and not use the native ES6 Promise implementation to do so. "
and
"The standards decision to hijack the previously nonreserved -- and completely general-purpose sounding -- then property name means that no value (or any of its delegates), either past, present, or future, can have a then(..) function present, either on purpose or by accident, or that value will be confused for a thenable in Promises systems, which will probably create bugs that are really hard to track down."
He praises immutability but ignores the fact that promises add mutable hidden state between your call and callback.
He mentions that promises can silently swallow errors and calls it the "Pit of Despair". There is much more. Read the chapter.
Pit of despair indeed.
Callbacks are so much simpler and beautiful:
https://medium.com/@b.essiambre/continuation-passing-style-p...