11–20 of 37 posts
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
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…
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?
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.
errr. require('async')?
seems like some NIH thinking in crockford land
[1] https://github.com/douglascrockford/RQ/commits/master [2] https://github.com/petkaantonov/bluebird/commits/master?page...
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.
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.
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…
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?
Earlier quoted context omitted.
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?
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?