9 ms·
RQ – A small JavaScript library for managing asychronicity
- hamburglar 11y agoI 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 11y agoYeah 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?
- prayerslayer 11y ago+1 for tests.
- bshimmin 11y agoFrom 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 11y agoI 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
- thomasfoster96 11y agoI'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 11y agoThe 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 11y agoI'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.
- esailija 11y agoIt doesn't matter at all what kind of promise flavor an API returns because promise implementations treat other implementations as interchangeable. Even the ES6 Promises implementation supports this: Promise.all([{ then: function(r) { r(3); } }]).then(function(result) { console.log(result); }); Here the plain object with then could have been any promise implementation, even jQuery, and it still works.
- thomasfoster96 11y agoI do understand that, but it'd be very nice to be able to do some things like timeouts and the like, without loading quite a few kilobytes of another promise implementation.
- outside1234 11y agoerrr. require('async')?
- bisrael 11y agoexactly what i was thinking. seems like some NIH thinking in crockford land
- chjj 11y agoMaybe 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.
- sturadnidge 11y agoDespite 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!
- alessioalex 11y agoHe didn't even include a package.json, shish.
- tejohnso 11y agoLooks 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 11y agoThat 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.)
- latchkey 11y agoLooking 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=42 https://github.com/petkaantonov/bluebird/commits/master?page...
- onion2k 11y agoI was thinking "Why not q?" That was started in 2010. https://github.com/kriskowal/q https://github.com/kriskowal/q
- kondro 11y agoPeople 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 11y agoThat'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.
- Ciantic 11y agoMust 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 11y agocould you please explain why you think typing is a wrong direction?
- unklefolk 11y agoThe reference is to Crockford not liking typing. Here is one link backing that up: https://plus.google.com/u/0/+DouglasCrockfordEsq/posts/MgzNUSTwjRt https://plus.google.com/u/0/+DouglasCrockfordEsq/posts/MgzNU...
- domenicd 11y agoCrockford is no longer in TC39 and hasn't attended for quite some time now (maybe a year).
- UserRights 11y agoThere is also https://github.com/mbostock/queue https://github.com/mbostock/queue 415 bytes minified and gzipped!
- amelius 11y agoIt 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 (?)
- dereke 11y agopogoscript.org has some nice features to let you use async like it was sync. fs = require 'fs' mojo = fs.readFile 'mojo.txt' 'utf-8' ^! console.log (mojo) (note that if readFile returned a promise you wouldn't need to use the ^)
- trevorgerhardt 11y agoES7 async/await functions? https://github.com/jaydson/es7-async https://github.com/jaydson/es7-async Babel already enables them.