errr. require('async')?
Despite stating that this is intended for server side use, he's also ignoring a major node / io convention with 'callback(success, failure)' - that alone will probably kill it for many us!
RQ – A small JavaScript library for managing asychronicity
21–30 of 37 posts
Re: RQ – A small JavaScript library for managing asychronicity
#22Looks interesting but some direct comparisons to es6 promises would really help. Favourite function description quote: "RQ.parallel does not add parallelism to JavaScript. It allows JavaScript programs to effectively exploit the inherent parallelism of the universe." Favourite variable name: untilliseconds
That opens the door for a whole bunch of portmanteau names for common time-related variables:
afterilliseconds sincilliseconds againilliseconds beforilliseconds pollilliseconds intervilliseconds
(I may start using intervilliseconds, just to drive some people crazy.)
Re: RQ – A small JavaScript library for managing asychronicity
#23Looking at the commit log [1], this code started in May 2013. That might explain why you might be thinking - why not async|bluebird|Promises? It looks like bluebird didn't start until Sept 2013 [2]. [1] https://github.com/douglascrockford/RQ/commits/master [2] https://github.com/petkaantonov/bluebird/commits/master?page...
I was thinking "Why not q?" That was started in 2010.
Re: RQ – A small JavaScript library for managing asychronicity
#24Earlier quoted context omitted.
The most popular[1] promises library (Bluebird) already has support for all of that, I think? .timeout() can be added to any promise chain to add a timeout, and there's .some(), .race(), .settle(), and .any(), etc. to handle various flavours of optionality. [1]: Well, based on comments on HN and Reddit. Not sure about hard numbers, but it certainly gets talked about a lot.
I'm more interested in these sorts of features being in the ES6 Promises implementation. I expect that given a lot of new Web APIs are going to be using the native promises, these features being in the ECMAScript promises implementation is pretty important.
For good or ill, it's not going to happen. ES6 is meant to have a VERY small promises API (although you can use a library like Bluebird as a wrapper around the native implementation to provide a better API). A more full features promises API will be coming in ES7.
See, for example, the discussion about adding a .any() method to the ES6 promise spec: https://esdiscuss.org/topic/promise-any
The conclusion basically that yes it would be useful, but it'll have to be ES7 not ES6.
Re: RQ – A small JavaScript library for managing asychronicity
#25Must be frustrating for Crockford to be in TC39. He didn't like class keyword, thought typing (TypeScript etc) is a wrong direction. This (albeit it began 2013, but it was just updated) library does not mention ES6 Promises, proposal for async await, or the yield hack.
could you please explain why you think typing is a wrong direction?
Re: RQ – A small JavaScript library for managing asychronicity
#26Must be frustrating for Crockford to be in TC39. He didn't like class keyword, thought typing (TypeScript etc) is a wrong direction. This (albeit it began 2013, but it was just updated) library does not mention ES6 Promises, proposal for async await, or the yield hack.
could you please explain why you think typing is a wrong direction?
The reference is to Crockford not liking typing. Here is one link backing that up:
https://plus.google.com/u/0/+DouglasCrockfordEsq/posts/MgzNU...
Re: RQ – A small JavaScript library for managing asychronicity
#27errr. require('async')?
exactly what i was thinking. seems like some NIH thinking in crockford land
Maybe Crockford is a bit behind the times. In the good old days, if it were still 2011, this wouldn't be NIH. Back then, everyone was still writing their own async flow control libraries. It was like a rite of passage into the node world. I remember my first one: https://github.com/chjj/N
I'm sure every early node person here has one, even if they didn't push it to github.
Looking back at it, I'm suddenly feeling a bit nostalgic for those days.
Re: RQ – A small JavaScript library for managing asychronicity
#28People keep comparing this to Bluebird, which is great and all, but Bluebird's JS is 72KB minified, whereas this library is just 3KB. That's what makes this a "small" JavaScript library for managing asynchronicity. And when you're using it for things like choosing which ads to display, etc (like some of the examples) you really don't want your JS load overhead to be very high.
That's true, but given the gradual shift to ES6 features over time you're more likely to end up using something like Bluebird (e.g. to complement your generators) and so having another library to then handle asynchronicity (and that too with callbacks) would be redundant.
Re: RQ – A small JavaScript library for managing asychronicity
#29errr. require('async')?
He didn't even include a package.json, shish.
Re: RQ – A small JavaScript library for managing asychronicity
#30It is kind of nasty to break your code into basic blocks, and tie them using library functions. This will certainly not make things much cleaner!
I was hoping one day Javascript could support "deep" coroutines, so we can keep on programming "sequentially" as we did before while still using asynchronous mechanisms.
Perhaps there exist languages that compile to Javascript, that offer deep coroutines (?)