Comparison with ES7 / Babel / regenerator about asyncawait HOT 6 OPEN

@stanleyxu2005 once you can use native async/await, I'd recommend migrating away from this library to the native syntax. In most cases it should be as simple as removing the extra parentheses (unless you make use of deep awaits, which aren't supported in the native syntax).

As for performance, I doubt it would matter much in real-world scenarios. Fibers (used by this lib) were much faster than ES6 generators in tight loops in V8, because V8 did not optimise generator functions. I'm not sure if that's still the case, or whether it also applies to V8's async/await. Either way any perf difference is likely to go away with ongoing V8 optimisation.

from asyncawait.

@yortus I agree with @stanleyxu2005 await(function() ...) is better than the native syntax await function()....

from asyncawait.

Yep good idea, I'd like to add this when I get a chance.

from asyncawait.

I think it's a great idea. I have a lot of proficiency with Babel but am hoping to use this in a side project, a quick overview of differences would help a lot.

from asyncawait.

What will be the relationship of ES7? As the Node 7.x branch supports await/async natively already, I'm curious, for new application that can run in Node 7.x, is it still worthy to use awaitasync. Will it have notable performance downgrade etc. IMHO, await(function() ...) is better than the native syntax await function()....

from asyncawait.

@allenhwkim I think the developers can consider detect native async/await support and switch conditionally. Use native implementation for new node environment and use wrapper for old node environments. There is nothing we can do to change the async/await syntax but live with the fact. I'm now okay with it. The only thing I still not quite confident is need some tool to detect unproperly written code, otherwise I have to troubleshoot unhandled rejections in PROD environment.

from asyncawait.