It's a good overview. I'm thinking about it now :) Examples 3 and 4 are very neat. And they do make sense as a way to have a pipeline operate on a range of val

It's a good overview. I'm thinking about it now :) Examples 3 and 4 are very neat. And they do make sense as a way to have a pipeline operate on a range of values which may or may not have resolved yet. They promise consistency regardless of the "readyState" of the resource. And the syntax could even be shortened with property getters to something like: pipe.read(x).split.map(upper).join.write(y) Which is okay. There's still something I dislike about them. I really just like the pattern where everything is a separate service, which send messages to each other. You can have message queues, and all services can operate simultaneously, and distribute them across wherever, you can hot-swap them, they're totally de-coupled, parameter formats aren't limited to Node-style callbacks. And each service can be "programmed" with a state machine, so everything is totally declarative, and totally expressive. Throw in complex event processing and you can do anything. I just really like SoA, and think if you're going to bother trying to create a solution for the "async opportunity" you may as well do the most awesome one possible. I think I mostly get what promises do and how they're useful -- I don't get why I'd use them over just JSONP and callbacks for something where I'm not trying to create such an epic solution. Fundamentally tho I think one major reason contributing to my choice to not use promises is maybe I'm comfortable with the ambiguity of a value that a value hasn't resolved yet, I don't need to pretend there's something there when it isn't!! :) Or maybe I just have "trust issues", and I don't trust promises in general, no matter what language you say 'em in! :) Yeah, that's probably a reason contributing, too -- I like SoA because everything takes care of its own stuff. No need to promise, just do!!