[olalonde]

In theory, someone could write a Babel plugin that wraps all files with `(async () => { /.../ })()` and prepends all function/method calls with `await ` (I think). I personally like the explicitness but maybe it's just because I'm used to it. I also wonder how that would work with `Promise.all()`.

[wruza]

We're now sorting out things for third-party js library written manually that way. It is a mess.

>Promise.all()

Objects returned from yields_deep_inside() may be implemented as lazy-evaluated, i.e. only `print(result.items)` or explicit `await(result)` will yield upon use, while request will be sent immediately. Thus the order of execution will depend purely on natural use case, not on programmed await sequences/groups. Since js is not parallel, you'll touch A or B first, not both.

How to sort it all out is a responsibility of an event framework, not of green thread abstraction that is coroutine.

One more thing: idk how js optimizes endless closures that are spawned as promise callbacks, but Lua coroutine's yield/resume is as cheap as return from / pass control to a VM. No closures are created to retain state across async calls, because VM stack is state itself. I suspect wrapping everything in async-await will simply trash GC and VM performance. In a sense, asynchrony is only emulated in javascript with a cost, though I may be wrong and it all is optimized out. We have to wait for jsvm implementation experts to [dis]prove that.