Its been a few days that I got to learn about Generator functions in JavaScript which are introduced in ES6 version.

There were various places generators were explained but what seems too intriguing for me is the fact that everywhere it is said that

A generator function is a way to write async code synchronously.

The question that I want to raise is "Why is there so much need to introduce a pletely different programming strategy just for the sake of it?"

I understand the async nature of the JS code makes it difficult for a newbie to understand and debug the code but does it require a plete change in coding style altogether?

I maybe wrong or not pletely understanding the concept behind its introduction but being inquisitive about it all is what pelled me to ask this question.

Its been a few days that I got to learn about Generator functions in JavaScript which are introduced in ES6 version.

There were various places generators were explained but what seems too intriguing for me is the fact that everywhere it is said that

A generator function is a way to write async code synchronously.

The question that I want to raise is "Why is there so much need to introduce a pletely different programming strategy just for the sake of it?"

I understand the async nature of the JS code makes it difficult for a newbie to understand and debug the code but does it require a plete change in coding style altogether?

I maybe wrong or not pletely understanding the concept behind its introduction but being inquisitive about it all is what pelled me to ask this question.

• javascript
• ecmascript-6

Share Improve this question Follow asked Jan 5, 2016 at 5:25 invincibleDudessinvincibleDudess 1,79222 gold badges1212 silver badges1919 bronze badges 6

• 1 They're about more than writing async code: generators provide a function that can run forever, pausing at times, and allowing exchange of values both out of and into for iterations. – Sampson Commented Jan 5, 2016 at 5:28
• 1 Oh I agree on that but can you please give me a use-case where I would need that kind of function? – invincibleDudess Commented Jan 5, 2016 at 5:33
• 1 You could use them to generate GUIDs, access a data store, or more. I even built a text-based adventure game on top of one once, sending user mands in, and receiving player-status on each yield. That use was primarily driven by curiosity :) – Sampson Commented Jan 5, 2016 at 5:35
• if you look as the "pretend top-down" code that one can now make with generators, it's not exactly "newbie friendly", so i don't think that's a motivation of the implementation crafters. the real power will likely be apparent later when we start using custom iteration on huge/infinite/slow objects. – dandavis Commented Jan 5, 2016 at 5:43
• 3 Generators alone don't allow you to write asynchronous code "synchronously" (that sounds very misleading btw). Generators + Promises allow you do that. But it's still weird, and hence we will get async/await in the future. I think it's beautiful that async/await is nothing but generators + promises, but I always saw this as a (maybe well-planned) side effect of generators. – Felix Kling Commented Jan 5, 2016 at 5:56

 |  Show 1 more ment

3 Answers 3

Sorted by: Reset to default 4

Because closures are less convenient for simple iteration; simplifying syntax for reasonably mon tasks can be worth it, even if the language supported the same pattern before. Just pare:

function chain() {
    var args = Array.from(arguments);
    return function() {
        if (args.length === 0) return undefined; // Or some other sentinel
        var nextval = args[0].shift(); // Destructive to avoid copies or more closure vars
        if (args[0].length === 0) args.shift();
        return nextval;
    };
}
var x;
// a, b and c must be indexable, e.g. Arrays; we can't handle other closures without
// requiring some API specific protocol for generation
for (var nextchain = chain(a, b, c); (x = nextchain()) !== undefined;) {
    // do stuff with current value
}

to:

function* chain() {
    for (var i = 0; i < arguments.length; ++i)
        yield* arguments[i];
}
// a, b and c can be any iterable object; yield* can handle
// strings, Arrays, other generators, etc., all with no special handling
for (var x of chain(a, b, c)) {
    // do stuff with current value
}

Sure, the savings in lines of code aren't incredible. It's mostly just reducing boilerplate and unnecessary names, removing the need to deal with closures for simple cases, and with the for...of syntax, providing a mon mechanism to iterate arbitrary iterable things, rather than requiring the user to explicitly construct the initial closure and advance it by name. But if the pattern is mon enough, that's useful enough.

As noted in ments, a, b, c must be Array-like for the closure based approach (or you'd use a different closure based approach where the writer of chain imposes arbitrary requirements on stuff passed to it, with special cases for Array-like stuff vs. generator-like closures) and processing is destructive (you'd need to add more closure state or make copies to make it non-destructive, making it more plex or slower); for the generator-based approach with yield*, no special cases required. This makes generators posable without plex specs; they can build on one another easily.

Scenario 1 (Async) : You might have heard of the importance of writing “non-blocking” javascript. When we do an I/O operation, we use callbacks or promises in javascript to write non blocking javascript code.

Scenario 2 (Sync): running infinite loop in javascript eg: node -e 'while(true) {}' will possibly freeze your puter

With all of this in mind, ES6 Generators allow us to effectively “pause” execution in the middle of a function and resume it at some time in the future (async code synchronously)

Use case: Imagine you need to do something with a sequence of infinite values. Arrays won’t be helpful in that case instead we could use ES6 generator functions

var iterator = generateRandoms();   //suppose it is a generator function which loops through infinite sequence

//generator functions returns a next function which can be called anytime in your code to get the next value from the sequence

console.log(iterator.next());     // { value: 0.4900301224552095, done: false }
console.log(iterator.next());     // { value: 0.8244022422935814, done: false }

And as far as plexity is concerned, its a new syntax but would not take long to grasp it.

For further reading:

1. http://x-team./2015/04/generators-work/
2. https://msdn.microsoft./en-in/library/dn858237(v=vs.94).aspx

Actually, the generator function is not so much about asynchronous, it is more about a function that can be interrupted, how the flow is interrupted is determined by the caller of generator, through iterator -- more explanation below

function* ab3() {
  console.log(1);
  var c = yield 2;
  console.log(2);
  return 1 + c;
  console.log(3);
}

1. a generator function is a function that can be truncated in between

2. it's execution starts when iterator.next() is called, a generator function returns iterator when called

3. first call of next will run the statement of generator function till the first yield and it will return the yielded value

4. second call of iterator.next will run till next yield or return statement so it will take in the data passed through next(3) // (3 in this example) and store it in variable (variable to which the yield is assigned), var y = yield 2; so 3 will be stored in y; and statement execution till the return statment., it will return {done:true} over here because we have reached the end of the generator function

5. next execution ( 3rd here) of iterator.next() will return {value: undefined, done:true}, since nothing is further returned by generator function