Callbacks are imperative, promises are functional
blog.jcoglan.com
Callbacks are imperative, promises are functional
1–10 of 154 posts
Re: Callbacks are imperative, promises are functional
#2James does a good job of articulating why promises are such a useful abstraction, especially in JavaScript land. I've been working on a project recently that relies heavily on coordinating many asynchronously-populated values, and I don't even want to think about what the code would look like if we were wrangling callbacks manually.
We actually extracted our promises implementation from the work we've been doing, and released it as RSVP.js[1]. While other JavaScript promises libraries are great, we specifically designed RSVP.js to be a lightweight primitive that can be embedded and used by other libraries. Effectively, it implements only what's needed to pass the Promises/A+ spec[2]. For a comparison of RSVP.js with other promises-based JavaScript asynchrony libraries, see this previous discussion on Hacker News[3].
1: https://github.com/tildeio/rsvp.js
Re: Callbacks are imperative, promises are functional
#3 > If foo takes many arguments we add more arrows, i.e. foo :: a -> b -> c
> means that foo takes two arguments of types a and b and returns something of
> type c.
Other than that teeny thing, this article is awesome, and I fully agree. Promises are an excellent thing, and while I'm just getting going with large amounts of JavaScript, they seem far superior to me.
Re: Callbacks are imperative, promises are functional
#4" the decision, made quite early in its life, to prefer callback-based APIs to promise-based ones."
Rewind to the point when nodejs was being designed. In that world, in the context of javascript, callbacks were the only real pattern that existed. XHR? callback. Doing something in the future? callback.
If you imagine node trying to leverage the javascript ecosystem, callbacks were a no-brainer.
Re: Callbacks are imperative, promises are functional
#5" the decision, made quite early in its life, to prefer callback-based APIs to promise-based ones." Rewind to the point when nodejs was being designed. In that world, in the context of javascript, callbacks were the only real pattern that existed. XHR? callback. Doing something in the future? callback. If you imagine node trying to leverage the javascript ecosystem, callbacks were a no-brainer.
Various incarnations of the Promise monad have existed for quite a while, even in JS. The oldest one I can think of is MochiKit's Deferred, inspired by Twisted's. That one worked (and still does) seamlessly with any callback code.
Re: Callbacks are imperative, promises are functional
#6" the decision, made quite early in its life, to prefer callback-based APIs to promise-based ones." Rewind to the point when nodejs was being designed. In that world, in the context of javascript, callbacks were the only real pattern that existed. XHR? callback. Doing something in the future? callback. If you imagine node trying to leverage the javascript ecosystem, callbacks were a no-brainer.
Maybe so, but everything in this article goes back at least to the 90s with the E programming language (http://erights.org). Doug Crockford was involved in E. (Nowadays E's Mark Miller is on the Ecmascript committee.)
Re: Callbacks are imperative, promises are functional
#7" the decision, made quite early in its life, to prefer callback-based APIs to promise-based ones." Rewind to the point when nodejs was being designed. In that world, in the context of javascript, callbacks were the only real pattern that existed. XHR? callback. Doing something in the future? callback. If you imagine node trying to leverage the javascript ecosystem, callbacks were a no-brainer.
Various incarnations of the Promise monad have existed for quite a while, even in JS. The oldest one I can think of is MochiKit's Deferred, inspired by Twisted's. That one worked (and still does) seamlessly with any callback code.
(Twisted was inspired by the work I just pointed to in my answer. Not to take away from yours -- I wasn't familiar with MochiKit.)
Re: Callbacks are imperative, promises are functional
#8All the code and such a big abstraction for the first example when it could have done like this:
var result = [];
paths.forEach(function (i, file){
fs.stat(file, function (err, data){
result.push(data);
if (i === 0) {
// Use stat size
}
if (result.length === paths.length) {
// Use the stats
}
});
});
Re: Callbacks are imperative, promises are functional
#9" the decision, made quite early in its life, to prefer callback-based APIs to promise-based ones." Rewind to the point when nodejs was being designed. In that world, in the context of javascript, callbacks were the only real pattern that existed. XHR? callback. Doing something in the future? callback. If you imagine node trying to leverage the javascript ecosystem, callbacks were a no-brainer.
I'm not sure you've ever used XHR if you call it the callback pattern.
The XHR object is effectively a request and a response bundled up into one object that has promise-like traits. You attach event handlers to it to handle various state changes and scenarios, and then once you issue the request, the event handlers get invoked 0-N times. If it really was JavaScript callback-style, XHR would look like this:
window.xmlHttpRequest("GET", url, function (result, error) { ... } );
Honestly, the only way to classify node's callback-heavy design as a 'no-brainer' is if you excuse the design by saying no thought was put into it beyond simply doing what a bunch of other people were doing. If you put enough thought into how large applications will be built, and how difficult it is to build scalable, maintainable libraries, callback-passing style easily loses compared to promises.
Re: Callbacks are imperative, promises are functional
#10" the decision, made quite early in its life, to prefer callback-based APIs to promise-based ones." Rewind to the point when nodejs was being designed. In that world, in the context of javascript, callbacks were the only real pattern that existed. XHR? callback. Doing something in the future? callback. If you imagine node trying to leverage the javascript ecosystem, callbacks were a no-brainer.
This is simply false.
Here's a discussion about removing promises from node.js in 2010:
https://groups.google.com/d/msg/nodejs/RvNoQtoWyZA/ar_lYLhK8...