7 ms·

If you're doing Node.js, Caolan's async library is pretty much part of the standard toolkit. I know Caolan's been thinking about this and reworking it for a wh

If you're doing Node.js, Caolan's async library is pretty much part of the standard toolkit. I know Caolan's been thinking about this and reworking it for a while, so I'll be interested to see whether it manages to see significant takeup.

onestone 13y ago
Indeed caolan/async has been a de-facto standard until recently. But for me personally it has become obsolete, with the standardization of generators and promises.
- rubiquity 13y ago
  This. The best part of Harmony is to wipe libraries like this off the face of the planet. I dread the days of trying to pick between 10 different flow control libraries. A few years ago 5 new flow control libraries were coming out every month.
nailer 13y ago
From Great British Node Conf, maybe two months ago: a speaker talking about promises asked what people use for flow control: - promises: about 20% of the room. - async: about 80% of the room For me async.waterfall([list of functions]) is little nicer than 10 chained .thens(). And people advocating promises still keep saying it keeps things flat. No it doesn't, we're already flat because we're all using async. Stop pretending async doesn't exist and isn't massively popular. And way, way better documented. Q.spawn what? And this is the best promises library? Stack Overflow question: Simplest fs.readFile example with generators and Q? Current only answer: Q.spawn(function* () { … var data = yield Q.ninvoke(fs, "readFile", somefile); … }); Answer from Highland docs: var data = _.wrapCallback(fs.readFile)('myfile'); - What's Q (yes it's a module, but what does it mean? Is it supposed to a misspelt queue or something else? - What does 'ninvoking' something do? - Shouldn't I just be able to to put the variable declaration outside of the scope? - Why do competing Open Source implementations of the same standard exist? Can't there just one reference implementation? That's not the future. I might be really ignorant here. I probably am - I could read a shit tonne of docs to work out what this strange beast does and technically someone can probably do a better job answering that Stack Overflow question. But nobody has, because very few people know how to operate the current state of the art generators/promises setup. From the Q docs: "If you have a number of promise-producing functions that need to be run sequentially" No, I don't have a number of promise producing functions. Nobody in nodeland has that. I just have functions. I could read about turning them into promise producing functions, and calculate whether this abstraction layer is adding value, but then again, I could do productive work with async. And from the looks of it, Highland too.
- jonny_eh 13y ago
  Bluebird is the best promises library: https://github.com/petkaantonov/bluebird https://github.com/petkaantonov/bluebird
- jkrems 13y ago
  async: async.waterfall([ fn1, fn2, fn3 ], function(err, result) { }); Q: resultP = [ fn1, fn2, fn3 ].reduce(Q.when, void 0); resultP .then(function(result) {}); .catch(function(err) {}); If you chain thens in Q, you are not doing it right (imho).
  - nailer 13y ago
    Q docs show both. Either way: .waterfall() is still simpler.
    - bluepnume 13y ago
      It would be trivial to create a q.series or q.waterfall abstraction. The real benefits of promises are that we get back `return`, `throw`, `try` and `catch`, not that it makes our code 'look' more sequential, which is totally possible using callbacks and async.js.
    - tel 13y ago
      Waterfall is an easier top-level API that hides a clean low-level API. When it's all you need and it works well then you won't want to switch. When it breaks or you want it to behave better then a nice low-level API is beneficial.
- phleet 13y ago
  Promises aren't just about keeping things flat. The biggest value to me is being able to avoid the passing around of callbacks and them relying on varying conventions (some async are function(args, ..., callback(err, data)), some are function(args, ..., callback(data), errback(err)), some are function({success: callback, error: errback})). Promises solve this problem by not passing around callbacks _at all_. Instead you return the promise and let the consumer attach the callback itself. And once we have promises widely available and part of the standard library, the calling conventions will be standardized too. EDIT: I agree that as it stands, the lack of standardization of promises (jQuery's are mutable, for instance) is a pain, and that documentation could certainly be better.
alasdair_ 13y ago
Agreed, almost everyone at Groupon is using Async over the alternatives.

onestone 13y ago

Indeed caolan/async has been a de-facto standard until recently. But for me personally it has become obsolete, with the standardization of generators and promises.

rubiquity 13y ago
This. The best part of Harmony is to wipe libraries like this off the face of the planet. I dread the days of trying to pick between 10 different flow control libraries. A few years ago 5 new flow control libraries were coming out every month.

nailer 13y ago

From Great British Node Conf, maybe two months ago: a speaker talking about promises asked what people use for flow control: - promises: about 20% of the room. - async: about 80% of the room For me async.waterfall([list of functions]) is little nicer than 10 chained .thens(). And people advocating promises still keep saying it keeps things flat. No it doesn't, we're already flat because we're all using async. Stop pretending async doesn't exist and isn't massively popular. And way, way better documented. Q.spawn what? And this is the best promises library? Stack Overflow question: Simplest fs.readFile example with generators and Q? Current only answer: Q.spawn(function* () { … var data = yield Q.ninvoke(fs, "readFile", somefile); … }); Answer from Highland docs: var data = _.wrapCallback(fs.readFile)('myfile'); - What's Q (yes it's a module, but what does it mean? Is it supposed to a misspelt queue or something else? - What does 'ninvoking' something do? - Shouldn't I just be able to to put the variable declaration outside of the scope? - Why do competing Open Source implementations of the same standard exist? Can't there just one reference implementation? That's not the future. I might be really ignorant here. I probably am - I could read a shit tonne of docs to work out what this strange beast does and technically someone can probably do a better job answering that Stack Overflow question. But nobody has, because very few people know how to operate the current state of the art generators/promises setup. From the Q docs: "If you have a number of promise-producing functions that need to be run sequentially" No, I don't have a number of promise producing functions. Nobody in nodeland has that. I just have functions. I could read about turning them into promise producing functions, and calculate whether this abstraction layer is adding value, but then again, I could do productive work with async. And from the looks of it, Highland too.

jonny_eh 13y ago
Bluebird is the best promises library: https://github.com/petkaantonov/bluebird https://github.com/petkaantonov/bluebird
jkrems 13y ago
async: async.waterfall([ fn1, fn2, fn3 ], function(err, result) { }); Q: resultP = [ fn1, fn2, fn3 ].reduce(Q.when, void 0); resultP .then(function(result) {}); .catch(function(err) {}); If you chain thens in Q, you are not doing it right (imho).
- nailer 13y ago
  Q docs show both. Either way: .waterfall() is still simpler.
  - bluepnume 13y ago
    It would be trivial to create a q.series or q.waterfall abstraction. The real benefits of promises are that we get back `return`, `throw`, `try` and `catch`, not that it makes our code 'look' more sequential, which is totally possible using callbacks and async.js.
  - tel 13y ago
    Waterfall is an easier top-level API that hides a clean low-level API. When it's all you need and it works well then you won't want to switch. When it breaks or you want it to behave better then a nice low-level API is beneficial.
phleet 13y ago
Promises aren't just about keeping things flat. The biggest value to me is being able to avoid the passing around of callbacks and them relying on varying conventions (some async are function(args, ..., callback(err, data)), some are function(args, ..., callback(data), errback(err)), some are function({success: callback, error: errback})). Promises solve this problem by not passing around callbacks _at all_. Instead you return the promise and let the consumer attach the callback itself. And once we have promises widely available and part of the standard library, the calling conventions will be standardized too. EDIT: I agree that as it stands, the lack of standardization of promises (jQuery's are mutable, for instance) is a pain, and that documentation could certainly be better.

alasdair_ 13y ago

Agreed, almost everyone at Groupon is using Async over the alternatives.