JavaScript async/await implemented in V8

Post by tarikjn » Tue, May 17, 2016, 3:13 AM UTC

andrewstuart2 wrote: post #15

I have yet to see a convincing argument that this feature is necessary or even helpful beyond one-liners. The Q promises API, to me, is the right way to reason about asynchrony. Once you understand closures and first class functions, so much about complex asynchronous flows (e.g. multiple concurrent calls via Q.all, multiple "returns" via callback arguments) become so simple. The "tons of libraries" argument doesn't…

Post by jeswin » Tue, May 17, 2016, 3:16 AM UTC

ht85 wrote: post #29

Kinf of OT, but can anyone share their experience about using Babel's async/await in production instead of regular Promises? I'd love to hear about people who have used it in large and complex projects, from a debugging standpoint. As of now, using Bluebird (with its source in a different, blackboxed script), it is possible to follow the code execution through the event loop with async debugging, in a very elegant an…

Post by jdgiese » Tue, May 17, 2016, 3:24 AM UTC

dvlsg wrote: post #50

coldtea wrote: post #38

Earlier quoted context omitted.

Would it? IIRC Promise.all will run the two responses in parallel, but will not send the first into the map before both are finished.

Yes. They will be sent into map immediately, and Promise.all() will return a Promise which will settle when the mapped array is all settled (or one errors, but that's not really relevant to the question). We're really just awaiting the promise returned from Promise.all(), but mapping the original fetches into a "new" set of promises.

Post by calebegg » Tue, May 17, 2016, 3:31 AM UTC

dvlsg wrote: post #28

tanto wrote: post #16

Earlier quoted context omitted.

> (e.g. multiple concurrent calls via Q.all, multiple "returns" via callback arguments) How about: async function main () { try { const responses = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ]); const jsons = await Promise.all(responses.map(res => res.json())) } catch (err) { console.log(err) } } I think this is pretty clear and not needing any lib…

Just to be picky, but I believe you would be better off with this: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'), fetch('https://api.github.com/orgs/facebook') ]).map(promise => promise.then(res => res.json())); } catch (err) { console.log(err) } } This way, if one response was much quicker than the other, you could begin sending it through the `res.jso…

    async function main () {
      try {
        const jsons = await Promise.all([
          fetch('https://api.github.com/orgs/facebook'),
          fetch('https://api.github.com/orgs/facebook')
        ].map(promise => promise.then(res => res.json())));
      } catch (err) {
        console.log(err)
      }
    }

Post by nemild » Tue, May 17, 2016, 3:43 AM UTC

sotojuan wrote: post #57

viperscape wrote: post #19

Earlier quoted context omitted.

The try and catch inside the async function is also great. Curious though, is using const over let common? I usually use const for imports and module level globals, and let inside functions. I recently got back into javascript, and it's nice to see it flourishing.

I'm alone in this but I prefer `let` over everything else unless it's something like Redux action strings, database connections strings, or anything of the like. I rarely use `const` for the ridiculous reason that I find it too long (5 characters!). `let` is short and reads nicely and my programming style in general never mutates stuff anyway (I use Ramda/always return new data). That said, `const` is picking up to b…