[just2n]

Promises are just tools for managing a list of callbacks with less boilerplate. I wouldn't call one imperative and the other functional. Both are functional. You might dislike callback patterns, but through one of the beautiful parts of JS, you can trivially wrap any callback-oriented API you want and have it become a promise based one. I've done this before when I had a very complex dependency graph at the start of a program and a few API calls were callback related. It looks something like this:

    SomeClass.prototype.someActionPromise = function(){
        var deferred = makeADeferred();
        SomeClass.prototype.someAction.call(this, function(err){
            err ? deferred.reject() : deferred.resolve();
        });
        return deferred.promise();
    };

Now you have a promise-based version that makes your code a little cleaner and easier to read.

[naradaellis]

The author "promisify"s a callback-based API in the article - which is worth a read by the way.

I'm interested in your opinion RE: his argument for why callback APIs are imperative - because I think he has a very good point and has supported it with a solid argument and you haven't offered any rebuttal.

[just2n]

Interesting. As you pointed out, I hadn't read the article but was rather replying to other comments.

After reading it, I think I have to agree that I had never thought about it that way. It makes a lot more sense that a promise is just a declaration of some unit of work, and when you can use a promise like any other data, you aren't just giving imperative commands, but rather describing work to be done and using that as a fundamental part of your code, which is why it drastically simplifies async programming (the relation of promises to monads is quite nice, too). Definitely a good article, thanks for kicking me :).