Oh ok, was just wondering about your reasons and that clears things up. That's a good read as well. But I think promises give you a way to compose them in a way that callbacks don't. With promises you can call easily call a function when multiple promises are fulfilled.
Actually would argue that Promises are less composable since you're forced to use whatever control flow paradigm the Promise library has provided or add another library to handle control flow.
By utilizing callbacks, you are free to use Async.js[0] or Step.js[1] to solve the problem you described. These libraries are great since they give you control over parallel vs series execution of the pre-requisite functions as well as solving more complex control-flow problems such as throttling, etc[2] (See link for more examples).
edit: Yes, you can also use similar control-flow libraries with Promises (that follow the specification) to achieve similar results but then the argument for using promises for the sake of control-flow breaks down.
At least a part of promises, the then function, is standardized through Promises/A+. This way you can easily combine different promise libraries to do things like:
- sequential execution
- parallel execution and wait for all of them to finish
Both interfaces can be abused to give you an ever growing indent and give the appearance of "callback hell"
Both interfaces can be use elegantly to help you reason about your code, make it easy to follow, and handle errors centrally.
Only one is supported natively by node.js and is the standard async interface for 90% of node.js's libraries: Callbacks.
Also, regarding "callback hell", a straw-man argument against callbacks, I highly suggest reading http://callbackhell.com/