Generators in JavaScript - What, Why and How - FunFunFunction #34

[@qwarlockz8017]

I still go back to your old vids to refresh on different subjects. I do miss you out there making content. Hope you are doing GREAT!

[@punio4]

The music is a bit distracting in this video. Might be the volume.

[@wundersoy]

Im 3 minutes into the video and the music is it playing lmao

[@amypellegrini1732]

I went to the middle of the video only to check if the music was still on and it wasn't, otherwise it would have been terribly annoying.

[@mydemon]

@@amypellegrini1732 yeah the music goes away at 1:57 thank God

[@PetrKohut]

I think one of the best reasons to use generators (co, or Bluebird coroutine) is when your promise chain has conditions according to which you have to do some other async operations or just go to next promise. Try to write some, and you will see ;). Btw: Best JS youtube channel. Love all your videos ;).

[@relativezero_]

Agreed. I have encountered such situation and co just solved it gracefully without any repetition of code.

[@josecaodaglio]

async / await.. much better

[@ianclark001]

@mpj I think a better example to think about how you'd use generators might be to create a generator which, for each iteration, returns the first Monday of next month. The point is the generator can yield results ad infinitum, but the caller will only want a certain amount. The caller therefore yields the results until it's gotten all the Mondays it needs to do whatever it is that it needs to.

This comment brings up a great point. mpj’s exercise uses a generator as a protagonist (the piece of code that concerns itself with what he actually wants to get done) and run() as a generic utility that will blindly run his generators for as many iterations as they will yield. In that context, and especially as a dumb promise-resolver, I have to agree with mpj that generators aren't all that exciting. Your example is an inverse use of generators (and one that I suspect is more suited to its strengths), where they are treated as a utility that helps our protagonist functions achieve repetitive and possibly verbose functionality in an iterative manner until the real task at hand no longer requires it. They are certainly both valid uses of generators, of course, but your example illustrates where, in my opinion, their real value lies.

[@SylvainPOLLETVILLARD]

what is the difference between using generators and using a recursive function in this example ?

[@ianclark001]

+Sylvain POLLET-VILLARD fundamentally very little. Generators _can_ be used to do things which are not as practical to do through recursion (multiple yields in multiple, nested loops if you're truly a masochistic e.g.), but some would just see a generator as being clearer than the recursive option. Similar to Alfonso's point, it also means that the _caller_ decides when to call it quits, whereas in recursion the recursive method must have a break case.

[@odw32]

@mpj, @ianclark001: They're indeed great for implementing modular arithmetic (stuff which cycles around infinitely like clocks, weeks), especially when you need special conditions (like leap years). But generators are also extremely good for functional programming, especially when you combine various *composable* and *infinite* generators with a "limiting" generator and destructuring operators like let array = [...g()] and let (a,b) = g(). In Haskell, this is called Lazy Evaluation. You could view a generator as an infinite array, and you use various transformations/conditions on that infinite array, before requesting a manageable subset (comparable to the take function in Haskell). With generators, implementing list functions like transpose, intersperse and various folds for infinite data structures can look quite elegant: gist.github.com/okdewit/017ee6612ca116dc89a27192eb5e9987

[@funfunfunction]

I get that is a common use case but I don't get why we'd need generators for that? Why not just make this as a function that returns a function that you can call to get the next value? function makeMondayIterator(startMonth) { let lastMonth = startMonth return function next() { lastMonth++ // calculate and return monday of next month here } }

[@jeffdickey]

Generators have an obvious use case, which you touch on at about 25:40: they let you write procedural, step-wise code (as you have in your generator example that gets passed to `run`) that use and depend on asynchronous code as though it were synchronous. HUGE win for simplifying code and avoiding callback hell. There are *no* visibly-explicit traditional callbacks in the generator code itself; the code that *runs* the generator (`run`, `co`, or whatever) takes care of that nastiness for you. As someone who has been writing code for a living since '79(!) and generally learns (or relearns) at least one or two new languages a year, I LOVE your videos. Great attitude and presentation skills, and the periodic diversions into less-than-obviously-related topics are welcome. Keep up the great work!

[@harisrg92]

Doesn't async await also do that? If I have to chose between async await and generators, I chose async await?

[@MaxNaruto1000]

@@harisrg92 it based on generators

[@Basha502]

@@harisrg92 We can't cancel the promises with async/await, if you don't want to add a complex behaviour or your use case is simple you can go with async/await

[@TheShneek]

I got all excited this morning then told my wife that FunFunFuncition is my Saturday Morning Cartoons (But I usually have to go to work afterwards)

[@funfunfunction]

+TheShneek haha, awesome!

[@purposepowerlove]

Generators are fantastic for multi-step file system operations. You need to wrap most Node APIs using a lib like thunkify (e.g. thunkify(fs.readDir) ), but once that is done if you use co it is wonderful! For one example, imagine you just 1) yield readDir, check for what you want, then 2) yield readFile, then make your changes and 3) yield writeFile, but it must be zipped so then 4) yield archive, and then 5) yield ensureDir, and finally 6) yield move to send the file to the final location. You can imagine how deeply that would be nested. With generators, it's a piece of cake!

[@lpaulger]

I feel like the current use of generators are just an overly complicated way of what "async await" will be in the next ES2016 - github.com/tc39/ecmascript-asyncawait. I agree that for now, promises are more straight forward for what most web developers are doing. Also thanks for adding the background music reference :)). I'm still trying to figure out the background music from kzbin.info/www/bejne/oqPJZ6ure9Zkg9U episode. Side note: You really moved me with the dramatic reading today... I am a new man... Keep up the good work!

[@SeanJMay]

That's a fair feeling; the coroutine pattern (and its userland implementations) is actually what makes the async/await pattern viable in the future.

[@eugeniogonzato]

I know it is long time you left KZbin, and I don't know if you still read the comment, but I have to tell you, your video is so helpful, well explained, and you are inimitable!! unique!!

[@bagoquarks]

Great examples. Freeze vid at 24:45 and ponder lines 20-28, especially line 25. The "next" method is called within a "then" within the "iterate" function that is used recursively to process a sequence of "yields" that control promises. It works - each promise is fulfilled before the next is invoked. .

[@TheLiebgott]

I'm glad you talked about "why" you're convinced with generators. I agree and I'm usually more comfortable with promises and async/await.

[@lucaszapico926]

Ok...I don't normally add to the internet conversation....but I think you're my favorite KZbinr! That intermission was blooming hilarious! Thanks for entertaining the heck out of me while still significantly helping me become a better developer! You're a hero! 🚀😁

[@marcosfprodrigues]

I'm half into the video and I'm way too bothered by the fact that you mistakenly called that variable `anotherIterator` instead of `anotherIteration`. My OCD won't let me sleep tonight!

[@error.418]

you are not alone XD

[@error.418]

***** No, it's a good trait to have when doing things like naming variables. He's perfectly fine being annoyed by it.

[@vincentbirebent2569]

Being bothered is not the point. I think it's worth fixing this slips or typo or whatever named error. Because it's not an iterator. When someone watching this is new to the knowledge it might mix things up for him. IMO the fix would be helpfull.

[@lolcat_host]

Answering your question: I think the value of generators is around error handling: the ability to simply `try...catch` errors in asynchronous flows is really helpful.

[@MikeNeder]

Been trying to figure out what Generators are all about. This video makes me think they are overly complicated for no apparent reason. As mpj said in the end of the video, I too would like to see more practical uses of them.

[@georules]

Completely on board with your analysis of the usefulness of generators. I've always assumed previously that there was just something I didn't understand about them versus what I was doing with promises.

[@harry3life]

the big advantage with generators is not that it can be used to make async code look synchronous but rather that can you lazily evaluate iterators on demand. Let's say you want a function that can generate all primes or just a very very large range. A generator allows you to on demand generate the next value without having to keep the entire sequence on hand (Which isn't possible with a list of all primes for example.)

[@funfunfunction]

+harry3life sure, but I can simply do that with callbacks.

[@ciachowski2]

Since generator can be used as iterator, it of course allows you to lazy evaluate code, but it is not everything. It is compatible with features like "for of" loop or array spread, and so with every algorithm that uses iteration methods. It gains the possibility to write simple asynchronous sequential code in declarative way, so no more callback hell. It allows you to write pure (side effect free) code by shifting the responsibility of evaluating not-pure functions inside generator up to the generator runner. Thanks to that, code becomes pure, predictable and a lot easier to test and maintain. This is of course not only exclusive for Promises.

[@dmh20002]

if you have seen the latest episode of Silicon Valley you'll understand this: Its hard for me to have a relationship with someone who doesn't use semicolons.

[@funfunfunction]

+david howard kzbin.info/www/bejne/h53VXnl9l81-l6s

[@dmh20002]

+funfunfunction 😆

[@richardnorris9030]

Love the video, but although recursion is a great feature, it should only be used when you can ensure the call stack is predictable and never going to exhaust the stack. A simple solution and always overlooked is to do a while around DONE then you will avoid a stack overflow problem, always try and implement with loops rather than recursion, can always handle many many more iterations.

[@benjamindowns]

I love your videos and recommend them to anyone that asks about functional javascript (especially for your first videos on .map, .filter, .reduce). And thanks for killing the music at 2:00! I know you need music as part of the production value of the video (along with your "lifestyle shots," etc....), but some of us can't focus while music is playing. Again, thanks. You are an excellent communicator.

[@funfunfunction]

+Benjamin Downs yeah, I generally try to tone it down when I need the full attention of people. ;)

[@wadewalker25]

Great vid man! Very well done, I love the honesty in your presentation!! I love the question why at the end!

[@marcosfprodrigues]

Excellent demonstration of how generators work! I've "learned" generators several times already, every time I need to read some examples to refresh my memory (all that talk about coroutines always confuses me), this example is probably going to stick.

[@cornedor93]

The example you're giving might also be solved with async/await if i'm not mistaken. Which makes it even harder to find good use cases for them.

[@SeanJMay]

The coroutine pattern demonstrated here is actually the underlying secret-sauce that makes async/await work in some future ES release (ES2017, hopefully).

[@voodoochile80]

Laughing and learning all the time. That's how it should be, thank you for putting this up!

[@inaccessiblecardinal9352]

Mpj, you are a big inspiration for me. Thank you for that. I watch your vids on stuff I already know, just because I know you will have a good perspective on it.

[@GregBailey71]

We have a UI Data Layer that abstracts our Axios calls (they are complex, involve polling, etc). I'm considering using them to return a function that will cancel polling and then issue a cancellation token for the active request, then yield the results of the axios call. The alternative is to just return an object with a function that will cancel the request and a promise I can use to resolve the result. Thoughts?

[@wmhilton-old]

Thank you for the clearest explanation of generators-as-the-new-promises usage! The piece I was missing was the need for an external "run" function. That explains the existence of all the "generator runner" libraries, like "co". From what I can tell, generators (which I think come to JS from Python?) were originally meant to solve the lazy-iterator problem. The whole terminology (iteration, next) makes sense for say, asynchronous queue processing. Their emergence as "the latest solution to callback hell" I think is premature. As seen in this example, it only moves the callback hell to solve other part of the codebase. Which is fine, if it's a green field application and you chose to do everything with "co" or one other the other generator runner libraries. But it's gonna be mental overload trying to combine code that's written for promises, generators, co, async, asynquence, and all these half-solutions that require a nonstandard library. :-( I'm hoping that the next version of JavaScript will provide a canonical solution to callback hell. I keep seeing references to "async/await" and wonder if that is going to be The One, our savior from (callback) hell, or just another false prophet?

[@3um]

So, do I get this right, co is a library that uses generators to make using promises nice like it is today with async/await and today using it where async/await is available doesn't make much sense?

[@funfunfunction]

Pretty much yes

[@mathiaspiletti]

You did a bad job explaning generators -im wondering how many is getting it, watching this as their first generators video. That sad, you still awesome and keep doing what you are doing. You are a true gem for javascript developers

[@nicolasschurmann]

The good thing about promises is that when you execute a then method to access the value of the resolved promise, you may return a value X to compose the promises. But you can also return another promise, in this case the value of the promise will be extracted and encapsulated into only one promise (like a chain in monads) therefore you can skip a "callback hell" an compose your functions. Also I agree with some guys that a better example will be something that needs to be executed forever and you just ask what you need. Other example would be to have an infinite scroll made with generators. You get access to the first 10 elements and add a counter, then you call for the next value that will get you the next ten. In this case generators are more exciting :)

[@rebornreaper194]

So Promise.then() can be used kind of like Array.map() in some cases? Like in the case where you have `.then(post => post.title)` (synchronous) just to use another .then() right after to log its value.

[@funfunfunction]

Yeah, something like that. Watch my talk on monads and functors to see how it all fits together: kzbin.info/www/bejne/aJvTaYFsfcZqqrs

[@rafaelgoesmann3399]

When should you yield promises vs generators vs thunks?

[@davidlormor]

Thanks so much for this great explanation! I finally feel like I get the basic premise of generator functions! I also like that you were honest at the end of the video in regards to generators' usefulness...I've seen them mostly used/referred to as "pause-able functions" as you mention, which feels like more of a handy side-effect than the intended use case. It makes me realize that using generators for async flow control may be somewhat of a neat trick (at best) or an antipattern (at worst)...but at least I feel like I "get" them now :) Cheers!

[@MulunehA]

Love the videos! The background music is a bit distracting ;)

[@bartsmykla]

It was funny, because I checked that it's Monday and there is no video from you, and when i came to your's channel there was a video added 1 minute ago. :-D I was faster than YT notifications. :-D

[@GuilhermeSS]

Great idea, I'll make a coffee and get back to watch you sir.

[@zenador15]

Hey man, Long time listener, first time caller I would love to hear you talk about css!! keep up the great work

[@cschmitz]

Do you have the non-spead up/music overlay version of you refactoring your run function to make it recursive? It's cool to see the end result, but it would also be helpful to watch/listen to you working through a problem. I find the times that I tend to learn new cool stuff is when I'm watching another dev work through an issue.

[@christianhorauf9958]

what a nice real world example for generators. since now, i only got introduced to them by number crunshing tasks, which is anyhow a very rare usecase for JavaScript from my point oft view. but this might be a usecase where generators prevail over promises. another nice side effect of combining promises and generators is the postponing of the promise until iterator.next gets called which otherwise only data.Task would do for you. but i see it like you: until now i had no real usecase for generators. thanks a lot for this good episode. :)

[@funfunfunction]

+Christian Hörauf yeah, perhaps I should find some semi-infinite stream case instead or something.

[@ahmedzs1]

Yeild/Generator = Pausable Function. Thank for this great video made me. It makes sense now!

[@Joenr76]

I've been told by a guy that used to be on the ECMA standards committee that generators are a precursor to C#-style async-await functions. If so, that would be a great addition, IMO. Another use (as mentioned by someone else) are infinite lists. Not something you need every day, but might come in handy. Most examples of generators I've come across use the Fibonacci sequence as an example. And I also use a French press at work.

[@mrmckeb]

That is what I've read too. Exciting times!

[@ViniciusDallacqua]

Nice one, generators is one of my favorite features to come. 'co' is the generator motor for Koa, and also offers a close abstraction to what is/will be async functions. Nice video mate, keep it up :)

[@mocheng]

Great talk! BTW, how do you highlight part of screen? Which software or shortcut do you use to shade the whole screen and only highlight small round-scope of it?

[@funfunfunction]

+Morgan Cheng Mouseposé.

[@rafaelgoesmann3399]

Hey, thanks for the videos. I just have a question at 6:19, why do you have to yield response.json()? I thought that yield was only used for asynchronous functions.

[@funfunfunction]

+Rafael Goesmann response.json() returns a promise.

[@xananacs]

`{value,done}` is not "anotherIterator", it's just an object with keys `value` and `done`, which is what iterators return ("done" is not mandatory until it is true, as per the spec). Very cool video, but I just wanted to point that out in case someone is confused.

[@efsgan]

Awesome! Just one thing. Command + K // This will clean your terminal and it will be easier to read (y)

[@funfunfunction]

+Eduardo Sganzerla I intentionally avoid using keyboard shortcuts, don't want to record keyboard. ;)

[@sirtobey1337]

Generators are really useful in contexts like KoaJS. I just used this for an api server I am writing. And while the hole promise thing is a nice benefit, where it really comes to use is saving you from callback hell when using a lot of Express-like Middlewares. It enables simple, clean code structure when passing down a request through your middlewares. I suggest taking a look at that :).

[@Salamaleikum80]

Hey what Microphone do you use? Sounds great :)

[@funfunfunction]

+ReaperPlayzLeague there is a behind the scenes episode

[@vincentgrafe6989]

For those looking for an use case in the wild (and who know a bit about redux), redux-sagas makes great use of generator functions.

[@gregduncan5993]

Do you have a video that shows us how we can set up and follow along on our own computer?

[@funfunfunction]

+Greg Duncan i just looked at this video and I literally show every single step of making this. Are you referring to installing node.js?

[@gregduncan5993]

I am using code vs on windows 10. I had no idea that you could simply do it like that - i though you had set up the before. Thanks. And thanks for the all the videos - I'm learning through lots of online sources groups. Your videos are often recommended and referred to, to help understand js concepts.

[@max8hine]

you can use the website codepen.io, to do it.

[@stephandevries5069]

I was just looking for some tutorials on this and I'm so glad you made some videos about ES6. Love your passion and they way you explain it all, thanks for the video's.

[@victorsalvans7418]

I used to use generators in Python in crawlers and they are very useful, because there is a lot of recursion, so it makes all responses available in a "flat way" .

[@bellekiller]

thanks bro, do you think it's possible to combine the two yield into one?

[@funfunfunction]

You need to specify time codes when commenting on a video that is 27 minutes long and two years old unless the creator of the video is rain man. :)

[@anshulsanghi8161]

I heard from a friend who is working on this library: github/jfet97/jducers which is basically using generators, yield etc. that the performance is bad because yield is a slow or expensive operation. Thoughts?

[@jasonfoster3196]

You, sir, are a poet!!! Thanks for the awesome videos, they make me less clueless :D

[@MrShezo88]

Thank for all the videos..Tusen takk..I have a question Jquery Ajax and Fetch which one you think is better beside the browser compatibility issues.

[@Shillputty]

In regards to the why - it seems like they're also important because they simplify the process of creating your own iterable object.

[@KimHogeling]

Off topic question. How do you darken your screen to highlight the area around the cursor? That would be useful to me for pair programming to prevent fingerprints all over my screen. Btw *as always* great video

[@funfunfunction]

+Kim Hogeling mouseposé!

[@KimHogeling]

cool, thanks for the reply

[@juliandavidtorregrosasimba7594]

How do you handle promise's errors with generators?

[@ahmedgaber3090]

Hi MPJ, I think generators are useful in case processing parent/child nodes. let me explain if u deal with Scrapy (python) if I crawl something like youtube channels so I will iterate over list of channels then yield each channel video into video parser. Let me know ur opinion

[@AndyHuggins]

Really like your videos and channel, thanks for making them! You often type out 'console.log()' you should make a snippet where you would type 'log' or 'l' and press tab, and it would automatically expand. Would save you time!

[@funfunfunction]

I intentionally don't do that, actually. I think that would distract from the content at hand. I don't use much hotkeys or plugins either, for the same reason. At worst, people get confused, and at best, they get impressed by the command and distracts from the subject that I'm talking about.

[@amilalisahil6882]

which softwere are you using to focus

[@HenriqueSchreiner]

Cool explanation about generators! Thanks for sharing it!

[@khai96x]

I used to thought generators are only for for-of loop, now I know another application of generators, thank to your video. Is there any other application of generators?

[@diegoamanjarres]

Hey mpj. I'm having hard time at work trying to convert them to node.js religion. Mostly because they are more used to sequential instructions like in java.Would you say that this *co* library, allows you to write async code in a sequential way? for those who are not used to async...

[@funfunfunction]

+Diego Manjarrés if you're not used to async, this is probably going to confuse things for a person. It doesn't make things sync, it just tries to encapsulate it. But your mileage may vary.

[@denisderkach8594]

We should now ganerators if we wanna write on something like Koa. Funfunfunction, ty, your videos are very useful and fun

[@eshuismultimedia]

Thanks for this video and all your other excellent videos! I have exactly the same feeling about generators. Right now the only sensible use case I can think of is combining them with promises. And in that respect, I feel that the readability of promises is just fine. Generators might give you more control over the execution of certain parts but I'm not exactly enlightened. I like the async and await spec much better. This makes it readable ánd simple in my opinion. I'm curious to see where this all leads to!

[@JoshuaKisb]

learnt about generators from php, use case was reading a large file, you dont want it all in memory. if its like 2GB, other use case i can think of is if you had to do like loading large dataset for a graph you can load as needed. basically memory efficiency

[@arindam11]

So, looking at just the video (no prior knowledge about generators) , it is similar to async and await in C#. True or not ?

[@funfunfunction]

+Arindam Banerjee you can think of is as a superset of async/await. It can do the same thing, but also a lot more.

[@arindam11]

+funfunfunction so, co can handle more than just promises ? (the equivalent would be Task) what other things can it do ? just one example would be sufficient, Thanks

[@OussamaBouguerne]

Awesome video as always!! The best use of Generators I've encountered is when using them with redux-sagas, IMO it would be very hard and nasty to try and implement redux-sagas using only Promises

[@MrNanomonkey]

Agh you poured the coffee now I need to go get a coffee before I can watch this!

[@lutaseb]

don't get the why of yielding response.json(). is it for the example? or is it the way to do ?

[@funfunfunction]

Response.json() returns a promise, yes, but there are like a million comments on this so it’s a widespread misconception that it returns synchronously.

[@lutaseb]

yeah i saw that on MDN, sorry for my question, I should have checked before

[@unautrejoureneurope]

May I know which software you use to record (and point the light on your cursor from time to time ;) ) ?? Thanks!

[@funfunfunction]

+Gabin Dsp see behind the scenes episode

[@blackdeckbox]

I'm just guessing but will generators work well with requestAnimationFrames? Wait until the animation finished then do something?

[@zephilde]

let nextFrame() => new Promise( ok=> requestAnimationFrame(ok) ) co(function *(){ stuff() yield nextFrame() blah = foo })

[@yumrin]

it's good know how it works. I'm now interested to know particular usecase that async/await can't achieve but the generator.

[@KamuelaFranco]

Thanks for this one. Co now makes sense. And using it still doesn't make as much sense. But I now get it.

[@joshuarowe8410]

Sorry if this has been asked before but, why do you always use const? is it better?

[@funfunfunction]

I don't always use it, but there is no need to make a variable mutable unless you need to mutate it. I sort of talk about this in kzbin.info/www/bejne/qZvce3WCasueppo In the language Rust, variables are actually immutable per default, which is a really great design decision: doc.rust-lang.org/book/second-edition/ch03-01-variables-and-mutability.html

[@joshuarowe8410]

funfunfunction thanks ! I didn't realise you already had a video on it haha

[@timsiwula]

That was a great depiction of the battery pack! 😂

[@danielmapar1]

Love you dude! cheers from Brazil

[@johnnyisji]

In my opinion, I think the use case for generators would be to pull data as needed, not to make async code look synchronous. Imagine building Tinder; you might fetch 50 profiles from the API at once using a generator function, loop over the results and yield each. Once you call the generator, you store the iteration somewhere (perhaps a data store). Now in your UI, as the user swipes through each person's profile, you can simply call `iteration.next()`, to get the next person's profile card. Once `iteration.done` happens, you can recall the generator function with some sort of an offset and fetch 50 more users from the API.

[@funfunfunction]

+Johnny Ji yeah, I get how it can be used for that, but that seems to be pretty easily implemented without them to me. I don't understand the need for a separate language construct.

[@asemzk]

I am at minute 7:40, and wondering why to use this thing instead of async/await, they do the same thing!!

[@funfunfunction]

You're looking at a video that was made fore async/await existed.

[@tying_wolf]

If you have a very big array of raw-data but you need to work with clean models in a loop, you don't want to map these data first on the classic way. Generators can be a solution to iterate over an array of models while you create it // --------------------------------- const data = [ {a: 1, b: 2}, {a: 2, b: 3}, {a: 3, b: 4} ]; function mapping() { return data.map(item => new Model(item)); } for(const item of mapping()) { console.log(item); } // --------------------------------- vs // --------------------------------- const data = [ {a: 1, b: 2}, {a: 2, b: 3}, {a: 3, b: 4} ]; function *generator() { for(const item of data) { yield new Model(item) } } for(const item of generator()) { console.log(item); } // --------------------------------- The solution with the generator only loop the whole data once, the solution with mapping will loop the whole data twice

[@reginaldojaccosantidade4364]

Great scene play. Touching 🤯

[@TarikHamilton]

What's your color scheme in your text editor? It looks like a better version of Solaris.

[@TarikHamilton]

Damn, came back to this video 2 years later randomly.

[@splace8466]

So yield is like breakpoint in gdb ?

[@apollyon144]

I think Co isn't *essential* but it really helps simplify code, when you have a long chain of promises, and you have to generate a value up here, then pass it through to the last step, and you accomplish that by declaring a variable outside your promise chain and then assigning it's value in step 3 of your promise chain and using it in step 6.... The code runs on, much like this sentence. You can do it in 1/3rd the code with co.

[@funfunfunction]

+Anastasi Bakolias care to post an example? I'd love to see it in practice.

[@ruegen_9443]

Nice episode! I don't see why I would use Generators yet unless for practical use I needed something to wait until it has finished running the fetch... I guess I need a practical use to go "hey, wow, I'm totally going to use that for x, y or z"...

[@ndstart]

What's the name of the font you're using, is it DEJAVU SANS MONO ? thank you

[@zephilde]

Hello! Thank you to make me finally understand co !! I never understand the co + generator thing... Now I understand that it's a early implementation of async function + await but without these keywords yet! :) I begin to use async + await (as it's supported by chrome 55), it's just awesome how the returned values are automagicaly transformed in Promise! By the way, I still don't understand well the use case of generators, I mean, the original use without co or any fake async function lib? I'm a bit disapointed, I thought you, funfunfunction, had given me some clues but you finally only speak of co (what is good still). What about generators with for .. of loops iterable interface and Symbol.iterator ?

[@larryscroggins]

Love your videos. They're great fun to watch and I get to learn something too. Are there any other channels that you could recommend to us?

[@brunohplemos]

Generators were the step necessary to make async/await possible in ES7, which are very cool / useful / syntax friendly

[@MubashirAR]

We could just use async await for such a scenario?

[@funfunfunction]

Note that you're commenting on a video that was made in a time where async await did not exist, and then the best case for it was to "implement" async await. For other examples of generators use in a world where we have async await you should watch the more recent playlist I've made on iterators and generators: kzbin.info/www/bejne/jWXFo3Sll6hlfsU

[@pradeepjain2872]

You are Awesome! Please do a video series on JavaScript design patterns and ECM6 if you can.

[@MarcelRobitaille]

What do you have against semicolons?

[@funfunfunction]

+Marcel Robitaille kzbin.info/www/bejne/h53VXnl9l81-l6s

[@MarcelRobitaille]

+funfunfunction missed that one somehow.

[@VeryBlueBot]

Thanks for this video! I subscribed a couple days a ago and already had a couple of 'aha' moments after watching your vids. this is one is one of them :) oh and a small nag: I usually watch videos on 1.5-2 speed so background music is a bit annoying and here is also too loud (even though it was only in the beginning). But maybe its only me. Other then that great stuff. Thanks!

[@anisdjer]

thanks for the video i use generators to avoid dealing with huge arrays of data, they allow me to deal with data by units

[@not_a_human_being]

isn't "response.json()" synchronous? is there a need for that second "yield"?

[@funfunfunction]

+Anton Loss no, it's asynchronous.

[@systemscholar]

I think promises are great, super useful, etc. That being said, generators do look like they are one step closer to abstracting away async patterns all together, which is the goal right?

[@yestintian857]

Taught me so much. Thank you!

[@BobbyBerberyan]

Thank you! You are the smartest person I know.😀