
RQ – A small JavaScript library for managing asychronicity - andrijac
http://www.rq.crockford.com/
======
hamburglar
I think I must be missing something, because this looks to me like a less-
elegant reinvention of the functionality of a handful of already extant
promise libraries. A library like 'when' already does all of this, and is much
more composable. As an obvious example, there is no reason to clutter up your
interfaces with specialized things like timeout parameters when a timeout
something you can transparently wrap on any promise without changing its
interface one bit.

~~~
BinaryIdiot
Yeah I feel the same way. So many others do this; hell I'm even building a few
of these into my current library. Seems like better language constructs for
handling asynchronous stuff will be nice (like ES6 promises though obviously
it doesn't do everything this library does but it does enough to make it
easier to do when needed).

Edit: Also where are the unit tests?

~~~
bshimmin
From a quick glance over Crockford's other repositories on GitHub, it doesn't
seem like any of them have unit tests. Is this something he's known for not
believing in?

~~~
BinaryIdiot
I thought he may have used JSDev[1] to do some unit testing (which I
understand why he set it up but it feels so awkward to me) but I don't see
anything. No idea; he's certainly talked about the privacy of closing methods
and unit testing but I thought he still did it just with JSDev.

[1]
[https://github.com/douglascrockford/JSDev](https://github.com/douglascrockford/JSDev)

------
kondro
People 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.

~~~
hiddentao
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.

------
latchkey
Looking 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](https://github.com/douglascrockford/RQ/commits/master)
[2]
[https://github.com/petkaantonov/bluebird/commits/master?page...](https://github.com/petkaantonov/bluebird/commits/master?page=42)

~~~
onion2k
I was thinking "Why not q?" That was started in 2010.

[https://github.com/kriskowal/q](https://github.com/kriskowal/q)

------
tejohnso
Looks 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

~~~
pavlov
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.)

------
Ciantic
Must 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.

~~~
vskarine
could you please explain why you think typing is a wrong direction?

~~~
unklefolk
The reference is to Crockford not liking typing. Here is one link backing that
up:
[https://plus.google.com/u/0/+DouglasCrockfordEsq/posts/MgzNU...](https://plus.google.com/u/0/+DouglasCrockfordEsq/posts/MgzNUSTwjRt)

------
UserRights
There is also
[https://github.com/mbostock/queue](https://github.com/mbostock/queue) 415
bytes minified and gzipped!

------
outside1234
errr. require('async')?

~~~
bisrael
exactly what i was thinking.

seems like some NIH thinking in crockford land

~~~
chjj
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](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.

------
amelius
It 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 (?)

~~~
trevorgerhardt
ES7 async/await functions?
[https://github.com/jaydson/es7-async](https://github.com/jaydson/es7-async)

Babel already enables them.

------
thomasfoster96
I'm not sure I'll start using RQ all the time over Promises, but this does
offer two nice features that Promises don't: optionals and timeouts. Optionals
could easily be implemented as some like Promise.some(), while
Promise.[all|some|race]() could all start taking an optional timeout
parameter.

~~~
Lazare
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.

~~~
thomasfoster96
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.

~~~
Lazare
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](https://esdiscuss.org/topic/promise-any)

The conclusion basically that yes it would be useful, but it'll have to be ES7
not ES6.

~~~
domenicd
The good news is ES7 is actually named ES2016, and will come out in one year.

The bad news is nobody has actually stepped up to champion such an addition,
so it's looking unlikely that such a feature would be implemented in 2
browsers by the mid-2016 deadline necessary for it to be part of ES2016.

~~~
thomasfoster96
ES2016? As far as I knew, the ES7 name was being kept, but the ECMAScript
script would be updated yearly, as opposed to the 5 or 6 years between ES5 and
ES6.

