RQ – A small JavaScript library for managing asychronicity

Post by dereke » Tue, Apr 14, 2015, 1:54 PM UTC

amelius wrote: post #30

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

  fs = require 'fs'
  mojo = fs.readFile 'mojo.txt' 'utf-8' ^!
  console.log (mojo)

Post by domenicd » Tue, Apr 14, 2015, 6:35 PM UTC

Ciantic wrote: post #17

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.

Post by thomasfoster96 » Wed, Apr 15, 2015, 9:55 AM UTC

domenicd wrote: post #34

Lazare wrote: post #24

Earlier quoted context omitted.

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 tha…

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.

Post by thomasfoster96 » Wed, Apr 15, 2015, 10:01 AM UTC

esailija wrote: post #10

thomasfoster96 wrote: post #7

Earlier quoted context omitted.

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.

It 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.