Difference between async/await and ES6 yield with generators

Question

I was just reading this fantastic article «Generators» and it clearly highlights this function, which is a helper function for handling generator functions:

function async(makeGenerator){
 return function () {
 var generator = makeGenerator.apply(this, arguments);
 function handle(result){
 // result => { done: [Boolean], value: [Object] }
 if (result.done) return Promise.resolve(result.value);
 return Promise.resolve(result.value).then(function (res){
 return handle(generator.next(res));
 }, function (err){
 return handle(generator.throw(err));
 });
 }
 try {
 return handle(generator.next());
 } catch (ex) {
 return Promise.reject(ex);
 }
 }
}

which I hypothesize is more or less the way the async keyword is implemented with async/await. So the question is, if that is the case, then what the heck is the difference between the await keyword and the yield keyword? Does await always turn something into a promise, whereas yield makes no such guarantee? That is my best guess!

You can also see how async/await is similar to yield with generators in this article where he describes the 'spawn' function ES7 async functions.

• David Haim: async function -> a coroutine. generator -> iterator which uses a coroutine to manage its inner iterations mechanism. await suspends a coroutine, while yield return a result from a coroutine which some generator uses
• Felix Kling: async/await is not part of ES7. Please read tag description.
• Alexander Mills: @david haim, yeah but async await is built on top of generators so they are not distinct

Answer 1

Well, it turns out that there is a very close relationship between async/await and generators. And I believe async/await will always be built on generators. If you look at the way Babel transpiles async/await:

Babel takes this:

this.it('is a test', async function () {
 const foo = await 3;
 const bar = await new Promise(resolve => resolve('7'));
 const baz = bar * foo;
 console.log(baz);
});

and turns it into this

function _asyncToGenerator(fn) {
 return function () {
 var gen = fn.apply(this, arguments);
 return new Promise(function (resolve, reject) {
 function step(key, arg) {
 try {
 var info = gen[key](arg);
 var value = info.value;
 } catch (error) {
 reject(error);
 return;
 }
 if (info.done) {
 resolve(value);
 } else {
 return Promise.resolve(value).then(function (value) {
 return step("next", value);
 }, function (err) {
 return step("throw", err);
 });
 }
 }
 return step("next");
 });
 };
}
this.it('is a test', _asyncToGenerator(function* () { // << now it's a generator
 const foo = yield 3; // <<< now it's yield, not await
 const bar = yield new Promise(resolve => resolve(7));
 const baz = bar * foo;
 console.log(baz);
}));

you do the math.

This makes it look like the async keyword is just that wrapper function, but if that's the case then await just gets turned into yield, there will probably be a bit more to the picture later on when they become native.

You can see more of an explanation for this here: https://www.promisejs.org/generators/

• Bram: NodeJS has native async/await for a while now, without generators: codeforgeek.com/2017/02/…
• Alexander Mills: @Bram native implementation absolutely uses generators under the hood, same thing, just abstracted away.
• Bram: I don't think so. Async/await is natively implemented in the V8 engine. Generators where a ES6 feature, async/await is ES7. It was part of the 5.5 release of the V8 engine (which is used in Node): v8project.blogspot.nl/2016/10/v8-release-55.html. It is possible to transpile ES7 async/await into ES6 generators, but with new versions of NodeJS this is no longer needed, and the performance of async/await even seems to be better then generators: medium.com/@markherhold/…
• Samarendra: @AlexanderMills can you please share some legit resources which says async/await uses generators internally? check this ans stackoverflow.com/a/39384160/3933557 which contradicts this argument. I think , just because Babel uses generators, it does not mean it is implemented similarly under the hood. Any thoughts on this
• Simon Buchan: The short version in V8, from what I can tell, is sort of. Yes, async is written using generator machinery: see this comment, but from what I can tell they are using internal APIs and specializing the bulitin impls to skip unnecessary checks - presumably because you don't have a handle on the generator object to do evil things on.

Answer 2

yield can be considered to be the building block of await. yield takes the value it's given and passes it to the caller. The caller can then do whatever it wishes with that value (1). Later the caller may give a value back to the generator (via generator.next()) which becomes the result of the yield expression (2), or an error that will appear to be thrown by the yield expression (3).

async-await can be considered to use yield. At (1) the caller (i.e. the async-await driver - similar to the function you posted) will wrap the value in a promise using a similar algorithm to new Promise(r => r(value) (note, not Promise.resolve, but that's not a big deal). It then waits for the promise to resolve. If it fulfills, it passes the fulfilled value back at (2). If it rejects, it throws the rejection reason as an error at (3).

So the utility of async-await is this machinery that uses yield to unwrap the yielded value as a promise and pass its resolved value back, repeating until the function returns its final value.

• Samarendra: check this answer stackoverflow.com/a/39384160/3933557 which contradicts this argument. async-await looks similar to yield but it uses promises chain under the hood. Please share if you have any good resource says "async-await can be considered to use yield".
• Arnavion: I'm not sure how you're taking that answer to be "contradicting this argument", because it's saying the same thing as this answer. >In the meantime, transpilers like Babel allow you to write async/await and convert the code to generators.
• Samarendra: its says babel convert to generators but what you are saying is "yield can be considered to be the building block of await" and "async-await can be considered to use yield.". which is not correct to my understanding (subject to correction). async-await internally uses promise chains as mentioned in that answer. i want to understand if there is something i am missing, can you please share your thoughts on this.
• Arnavion: This answer does not make the claim that all ES engines in the whole world internally implement promises using generators. Some may; some may not; it is irrelevant to the question that this is an answer to. Nevertheless, the way promises work can be understood using generators with a particular way to drive the generator, and that is what this answer explains.

Answer 3

what the heck is the difference between the await keyword and the yield keyword?

The await keyword is only to be used in async functions, while the yield keyword is only to be used in generator function*s. And those are obviously different as well - the one returns promises, the other returns generators.

Does await always turn something into a promise, whereas yield makes no such guarantee?

Yes, await will call Promise.resolve on the awaited value.

yield just yields the value outside of the generator.

• Arnavion: A minor nit, but as I mentioned in my answer the spec doesn't use Promise.resolve (it used to earlier), it uses PromiseCapability::resolve which is more accurately represented by the Promise constructor.
• Bergi: @Arnavion: Promise.resolve uses exactly the same new PromiseCapability(%Promise%) that the async/await spec uses directly, I just thought Promise.resolve is better to understand.
• Arnavion: Promise.resolve has an extra "IsPromise == true? then return same value" short-circuit that async does not have. That is, await p where p is a promise will return a new promise that resolves to p, whereas Promise.resolve(p) would return p.
• Bergi: Oh I missed that - I thought this was only in Promise.cast and was deprecated for consistency reasons. But it doesn't matter, we don't really see that promise anyway.
• Dejavu: var r = await p; console.log(r); should be transformed to something like: p.then(console.log);, while p might be created as: var p = new Promise(resolve => setTimeout(resolve, 1000, 42));, so it is wrong to say "await calls Promise.resolve", it is some other code totally far away from the 'await' expression that invokes Promise.resolve, so the transformed await expression, i.e. Promise.then(console.log) would be invoked and print out 42.

Answer 4

tl;dr

Use async/await 99% of the time over generators. Why?

1. async/await directly replaces the most common workflow of promise chains allowing code to be declared as if it was synchronous, dramatically simplifying it.

2. Generators abstract the use case where you would call a series of async-operations that depend on each other and eventually will be in a "done" state. The most simple example would be paging through results that eventually return the last set but you would only call a page as needed, not immediately in succession.

3. async/await is actually an abstraction built on top of generators to make working with promises easier.

See very in-depth Explanation of Async/Await vs. Generators

Answer 5

Try this test programs which I used to understand await/async with promises.

Program #1: without promises it doesn't run in sequence

function functionA() {
 console.log('functionA called');
 setTimeout(function() {
 console.log('functionA timeout called');
 return 10;
 }, 15000);
}
function functionB(valueA) {
 console.log('functionB called');
 setTimeout(function() {
 console.log('functionB timeout called = ' + valueA);
 return 20 + valueA;
 }, 10000);
}
function functionC(valueA, valueB) {
 console.log('functionC called');
 setTimeout(function() {
 console.log('functionC timeout called = ' + valueA);
 return valueA + valueB;
 }, 10000);
}
async function executeAsyncTask() {
 const valueA = await functionA();
 const valueB = await functionB(valueA);
 return functionC(valueA, valueB);
}
console.log('program started');
executeAsyncTask().then(function(response) {
 console.log('response called = ' + response);
});
console.log('program ended');

Program #2: with promises

function functionA() {
 return new Promise((resolve, reject) => {
 console.log('functionA called');
 setTimeout(function() {
 console.log('functionA timeout called');
 // return 10;
 return resolve(10);
 }, 15000);
 });
}
function functionB(valueA) {
 return new Promise((resolve, reject) => {
 console.log('functionB called');
 setTimeout(function() {
 console.log('functionB timeout called = ' + valueA);
 return resolve(20 + valueA);
 }, 10000);
 });
}
function functionC(valueA, valueB) {
 return new Promise((resolve, reject) => {
 console.log('functionC called');
 setTimeout(function() {
 console.log('functionC timeout called = ' + valueA);
 return resolve(valueA + valueB);
 }, 10000);
 });
}
async function executeAsyncTask() {
 const valueA = await functionA();
 const valueB = await functionB(valueA);
 return functionC(valueA, valueB);
}
console.log('program started');
executeAsyncTask().then(function(response) {
 console.log('response called = ' + response);
});
console.log('program ended');

Answer 6

In many ways, generators are a superset of async/await. Right now async/await has cleaner stack traces than co, the most popular async/await-like generator based lib. You can implement your own flavor of async/await using generators and add new features, like built-in support for yield on non-promises or building it on RxJS observables.

So, in short, generators give you more flexibility and generator-based libs generally have more features. But async/await is a core part of the language, it's standardized and won't change under you, and you don't need a library to use it. I have a blog post with more details on the difference between async/await and generators.

Answer 7

The yield+gen.next()-as-a-language-feature can be used to describe (or implement) the underlying control-flow that await-async has abstracted away.

---

As other answers suggest, await-as-a-language-feature is (or can be thought of) an implementation on top of yield.

Here is a more intutive understanding for that:

Say we have 42 awaits in an async function, await A -> await B -> ...

Deep down it is equivalent to having yield A -> tries resolve this as a Promise [1]

-> if resolvable, we yield B, and repeat [1] for B

-> if not resolveable, we throw

And so we end up with 42 yields in a generator. And in our controller we simply keep doing gen.next() until it is completed or gets rejected. (ie this is the same as using await on an async function that contains 42 await.)

This is why lib like redux-saga utilizes generator to then pipe the promises to the saga middleware to be resolved all at one place; thus decoupling the Promises constructions from their evaluations, thus sharing close resemblance to the Free Monad.

Answer 8

The idea is to recursively chain then() calls to replicate the behavior of await which allows one to invoke async routines in a synchronous fashion. A generator function is used to yield back control (and each value) from the callee to the caller, which happens to be the _asyncToGenerator() wrapper function.

As mentioned above, this is the trick that Babel uses to create polyfills. I slightly edited the code to make it more readable and added comments.

(async function () {
 const foo = await 3;
 const bar = await new Promise((resolve) => resolve(7));
 const baz = bar * foo;
 console.log(baz);
})();
function _asyncToGenerator(fn) {
 return function () {
 let gen = fn(); // Start the execution of the generator function and store the generator object.
 return new Promise(function (resolve, reject) {
 function step(func, arg) {
 try {
 let item = gen[func](arg); // Retrieve the function object from the property name and invoke it. Similar to eval(`gen.${func}(arg)`) but safer. If the next() method is called on the generator object, the item value by the generator function is saved and the generator resumes execution. The value passed as an argument is assigned as a result of a yield expression.
 if (item.done) {
 resolve(item.value);
 return; // The executor return value is ignored, but we need to stop the recursion here.
 }
 // The trick is that Promise.resolve() returns a promise object that is resolved with the value given as an argument. If that value is a promise object itself, then it's simply returned as is.
 return Promise.resolve(item.value).then(
 (v) => step("next", v),
 (e) => step("throw", e)
 );
 } catch (e) {
 reject(e);
 return;
 }
 }
 return step("next");
 });
 };
}
_asyncToGenerator(function* () { // <<< Now it's a generator function.
 const foo = yield 3; // <<< Now it's yield, not await.
 const bar = yield new Promise((resolve, reject) => resolve(7)); // <<< Each item is converted to a thenable object and recursively enclosed into chained then() calls.
 const baz = bar * foo;
 console.log(baz);
})();