Yes and no. Your code sample will fail on ..
You'd have to use
.. unless foo()'s resolve() returns the arguments a,b in which case you'd use ..
In any case, the real advantage of writing that code in that way is that it really isn't synchronous code. It's sequential, but not synchronous. It's asynchronous. The
foo() invocation could invoke some filesystem activity that takes a while, if running on node.js/io.js, or it could run a background worker in a separate thread if running on a modern browser, and in either case the promise wouldn't
resolve() and the next
The down side is that you must have a promise strategy in place and work with it. Where Neil said you should use a polyfill, which is true in that ECMAScript 6 isn't generally adopted yet, even if it was you must still work with its promise strategy. So your greater concern is that
bam() must return promises. Those promises must be objects that intercept a
reject() and pass them on to
.done() and to
.fail(), and they must chain for
.fail(). (There's more to promises than this, you'll need to do more research on this if you bake your own.) The existing promise frameworks including even jQuery's
$.Deferred are pretty elegant but the point is you're adding more work to your code.
So, really as Neil said you should only write your code in the promises syntax manner when you feel you're sequentially invoking methods that are expected to be long-running tasks. However, YAGNI; don't do it if you think they might be long-running tasks in the future, only do it if you know they're long-running tasks now. Don't optimize early until you've identified a bottleneck. But you also must consider the cost of promises. Don't write asynchronous code if you can't handle supporting the promise strategy.