Hacker News Reader

I love async/await, but it's really syntactic sugar for a thing you could already do in ES6 with generators. The coroutine pattern is absolutely the right way to go with async handling, but we already had it. Now we have a slightly nicer syntax for it.

View on HN

I don't think it can be considered syntactic sugar. For one, writing .then( .. => return ..) everywhere is too verbose and using co means that you are using a library to achieve something that the language should have first class support in the first place. Moreover, async/await will have different semantics than generators, the runtime will have native support and no generators will be involved. Calling these solutions "we already had it", IMHO, is like saying we didn't need functional programming features like .filter, .map etc, or newer features like Object.create, Object.assign etc we already had polyfills or other ways to a achieve their functionality. For that matter, even a simple "for loop" is redundant as you can use a while loop and use your own counter to achieve the same results. Async/await as a language construct feels so much better and fulfills a very common pattern than verbose solutions or solutions with different semantics using libraries.

I'm not positive, but I'm pretty sure that async/await is currently implemented on top of generators in all major engines. I know it's true of at least some engines.

Which makes sense. It's not a perf critical feature, so transpiling is the smart move.

Reply on news.ycombinator.com