> Unfortunately, using yield based solution will require third party libraries, which means increased payload and incompatibilities among frameworks. Check out

> Unfortunately, using yield based solution will require third party libraries, which means increased payload and incompatibilities among frameworks. Check out co (https://github.com/visionmedia/co/blob/master/index.js https://github.com/visionmedia/co/blob/master/index.js). For all its features it's tiny. Increased payload and incompatibility is a blanket statement; that could apply to any library or framework. > And I am also quite disappointed that the solution to one of JavaScripts biggest flaws requires hacking a language feature that was designed for an entirely different use-case, which will surely bring lots of confusion. There should be a really high bar for adding keywords to a language. If something can be solved with features we already have, we needn't add another. ES6 generators solves the callback problem for now. There are of course other (perhaps more flexible) solutions, like Scala's futures and for-comprehensions [1], or F# computation expressions [2]. But generators are simpler and they work well enough. [1] http://docs.scala-lang.org/overviews/core/futures.html http://docs.scala-lang.org/overviews/core/futures.html [2] http://fsharpforfunandprofit.com/series/computation-expressions.html http://fsharpforfunandprofit.com/series/computation-expressi...