3 ms·

Generators will likely be a new paradigm. They are too powerful for senior devs to ignore. And so the junior devs will be taught. Like promises were taught.

akritrime 7y ago
Wait that doesn't make sense, was generators in the language before Promises, actually isn't await based on generators? How is that a new paradigm?
- tchaffee 7y ago
  Promises and generators were ES6, so around the same time. Although people were using promises long before it became an official feature in ES6. I remember using promises as far back as 2012 or earlier - jquery had them. ES6 was 2015. Await and async came after in ES7 and can be considered to use yield[1]. So there you go - that's a perfect example of the power of generators. Promises used to be more difficult until they were simplified using generators. [1] https://stackoverflow.com/questions/36196608/difference-between-async-await-and-es6-yield-with-generators https://stackoverflow.com/questions/36196608/difference-betw...
ponyous 7y ago
I prefer to avoid them. Debugging can be way harder. Remember good old days when you could understand minified JS relatively easily? Look at webpack bundle + babel with generators. Horror to work with. Yeah, I know sourcemaps and all that, but even sourcemaps workflow is impacted; setting breakpoints can be weird, debuggers are still not perfect.
- tchaffee 7y ago
  I think you are mixing up concerns. Webpack + babel does make debugging harder in general. Because you are looking at the output of a compiler. But what does that have to do with generators? Do you have a specific concern about how Babel "compiles" generator functions using switch? Again, I tend not to look at compiled code, but I think the babel output for a generator function is easy to read.
nojvek 7y ago
Generators are great and I love them. So are promises. Yes, they do take a while to understand the underlying mechanics of iterators but I wouldn't call generators per say magic. The magic is "this.render". What is "this" in a function ? If we're storing any sort of state in this, then I expect to see "new <something>()", which creates a new this. By default functions inherit the this as window, and it's frowned upon to use "this" in pure functions. Crank.js breaks the convention where "this" is magically something else. It will also make it hard to typescript type the function. So now suppose you have mouse event handlers and key event handlers, when their functions get called, their "this" is something else and you have to bind it via either arrow functions or .bind(this). So my point is, because of unconventional "this", as a developer I have to keep track in my head what this refers to inside a function because it's implicit. If I am working with a team, I have to carefully explain that "this" is unlike what you think it is, it's magically injected. In javascript "this" is the source of many bugs, because it can be different things based on context. https://www.javascripttutorial.net/javascript-this/ https://www.javascripttutorial.net/javascript-this/

akritrime 7y ago

Wait that doesn't make sense, was generators in the language before Promises, actually isn't await based on generators? How is that a new paradigm?

tchaffee 7y ago
Promises and generators were ES6, so around the same time. Although people were using promises long before it became an official feature in ES6. I remember using promises as far back as 2012 or earlier - jquery had them. ES6 was 2015. Await and async came after in ES7 and can be considered to use yield[1]. So there you go - that's a perfect example of the power of generators. Promises used to be more difficult until they were simplified using generators. [1] https://stackoverflow.com/questions/36196608/difference-between-async-await-and-es6-yield-with-generators https://stackoverflow.com/questions/36196608/difference-betw...

ponyous 7y ago

I prefer to avoid them. Debugging can be way harder. Remember good old days when you could understand minified JS relatively easily? Look at webpack bundle + babel with generators. Horror to work with. Yeah, I know sourcemaps and all that, but even sourcemaps workflow is impacted; setting breakpoints can be weird, debuggers are still not perfect.

tchaffee 7y ago
I think you are mixing up concerns. Webpack + babel does make debugging harder in general. Because you are looking at the output of a compiler. But what does that have to do with generators? Do you have a specific concern about how Babel "compiles" generator functions using switch? Again, I tend not to look at compiled code, but I think the babel output for a generator function is easy to read.

nojvek 7y ago

Generators are great and I love them. So are promises. Yes, they do take a while to understand the underlying mechanics of iterators but I wouldn't call generators per say magic. The magic is "this.render". What is "this" in a function ? If we're storing any sort of state in this, then I expect to see "new <something>()", which creates a new this. By default functions inherit the this as window, and it's frowned upon to use "this" in pure functions. Crank.js breaks the convention where "this" is magically something else. It will also make it hard to typescript type the function. So now suppose you have mouse event handlers and key event handlers, when their functions get called, their "this" is something else and you have to bind it via either arrow functions or .bind(this). So my point is, because of unconventional "this", as a developer I have to keep track in my head what this refers to inside a function because it's implicit. If I am working with a team, I have to carefully explain that "this" is unlike what you think it is, it's magically injected. In javascript "this" is the source of many bugs, because it can be different things based on context. https://www.javascripttutorial.net/javascript-this/ https://www.javascripttutorial.net/javascript-this/