Write logic, not mechanics

Well put. It still puzzles me that promises and/or CPS don't have a greater adoption in the JavaScript community. I guess that what happens is that the concept of a callback is a very easy to understand one, but a system becomes more complicated and cumbersome (exponentially, I would say) with every new callback that is added to it. The real problem comes when creating big async applications in JavaScript based entirely in callbacks, as it is the norm now specially in NodeJS projects. Using callbacks to build complex applications is a sure way to un-maintainability.

It strikes me that this developer chooses to write an abstraction on top of JS for solving his recurring problems, over simply using language features readily available.<p>Promises are as much a pattern or mechanic as callbacks, but the latter feels far more natural in JS. The `promised` decorator is interesting, but it has problems:<p>- The application I work on, and have in mind with this, would need just about every function decorated.<p>- It doesn't account for methods, unless you're default decorating the method, ie.: `Foo.prototype.myMethod = promised(function(/* ... <i>/) { /</i> ... */ });`<p>- Every decorated function takes a noticable performance hit, because things like `Function#apply` and concatenating `arguments` are relatively slow.<p>- It doesn't sit well with me that the example rewrites a method on a prototype declared elsewhere: `console.log = promised(console.log)`<p>Further, the article and library don't even scratch the surface of complicated async flows. Think async versions of common functional-style methods like `map`, `reduce`, etc.<p>For example, a basic scenario from our own build process is: Scan a directory for template files, read them, compile them, then concatenate the result and write it out.<p>We used to have a promise library to do all of this, from handling a build process to performing database queries. I discovered Async.js at some point and haven't look back since: <a href="https://github.com/caolan/async" rel="nofollow">https://github.com/caolan/async</a>

<p><pre><code> it’s possible to make sync function async it’s not the case other way round </code></pre> Is this terminology correct? I thought it is easier to make async functions sync by blocking it, and harder to unblock a sync one. Am I confusing this with something else?

A good example of deferreds can be found in jQuery - every AJAX method returns a deferred that you can chain success, error, etc. handlers to. So it's not like this idea isn't a mainstream one.<p>The main problem I see is that very few libraries handle receiving promises as arguments, probably because there isn't a standard/widely-used implementation of them. So your logic ends up being backwards, e.g you'd chain Mustache.render off of a jQuery success promise, rather than just passing the success promise in.

The code doesn't actually work though, the very first example is broken:<p><pre><code> function sum(a, b) { return a + b } sum = promised(sum) var a = defer() // make promise var b = sum(a, 1) var b = sum(b, 5) console.log(b) // eventually prints =&#62; 17 a.resolve(11) // fulfill promise </code></pre> Prints:<p><pre><code> [object Object]15</code></pre>

For any node.js devs out there, here is the promises library I've been using with great success: <a href="https://github.com/coolaj86/futures/tree/v2.0/future" rel="nofollow">https://github.com/coolaj86/futures/tree/v2.0/future</a>

This is one of the simplest implementations of deferreds I've seen in JS so far.

The lack of semicolons in the article's examples makes me uneasy...

That last line<p><pre><code> return Mustache.render(template, data) </code></pre> Isn't exactly equivalent to the non-promise one, since now `Mustache.render` is async, is it?

I will be down voted for saying so, but "than" and "then" seem to be reversed throughout the entire article. I would like to learn more about promises now.

A very well thought out article.