Does async/await solve a real problem?

Jeswin Kumar jeswinpk at agilehead.com
Thu Sep 11 02:45:43 PDT 2014


Looking at my project (in which asynchronous calls are entirely done
via generators), I can't see how async/await would simplify code for
end-users like me (application programmers).

End users write the spawn()/Q.async()/co() wrapper *at most* one
single time in an application:
1. When using a framework like say koajs, you don't have to write it even once.
2. While not using a framework, you'd have to use the wrapper one
single time in say, the main.js file.

To use the example at
http://wiki.ecmascript.org/doku.php?id=strawman:async_functions

async function chainAnimationsAsync(elem, animations) { CODE; }
is just
function chainAnimationsAsync*(elem, animations) { same CODE; }
when flow control is done by a framework or at the entry point to your
application. spawn() isn't needed.

I can't see how this will reduce application's code even a little. So
my question is, is async/await needed?


One more question
--------------------------
1. yield is practically very difficult to use in a project because you
don't get proper stack traces (at least with the current flow control
libraries). You'd only see the last call which threw the error, and
then functions from the flow control library immediately below that. I
suppose the generators leading up to the erring generator are all
suspended and wouldn't be on the stack frame chain.

2. yield* generator delegation solves this problem, you get real stack
traces. I was able to get full stack traces simply by replacing all
yield X() with yield* X()

example code as in: https://github.com/chopachom/syncio

So if there are valid use-cases for adding async/await to JS,
shouldn't it be based on how yield* works rather than yield?

-- Jes

The Fora Project is coming...
https://github.com/jeswin/fora


More information about the es-discuss mailing list