JavaScript async/await implemented in V8 • Hacker News Board

Re: JavaScript async/await implemented in V8

#221

Post by z3t4 » Wed, May 18, 2016, 12:25 PM UTC

Promises are like cancer, and async/await is just treating the symptoms.

  // Callback
  dataCollection.find('somethingSpecific', function getIds(dataArray) {
    var ids = dataArray.map(item => item.id));
    display(ids)
  });


  // Promise
  var dataArray = dataCollection.find('somethingSpecific');
  var ids = pmap(dataArray, function(item) { // Cancer cell 
    return item.id;
  });
  pdisplay(ids); // Cancer cell 
  // The cancer grows ...
  function pmap (dataPromise, fn) {
    return dataPromise.then(
    function(data) {
      return map(data, fn);
    });
  }
  // The cancer grows ...
  function pdisplay(dataPromise) {
    dataPromise.then(function(data) {
      display(data);
    },function(err) {
      display(err);
    });
  }

Re: JavaScript async/await implemented in V8

#222

Post by WorldMaker » Wed, May 18, 2016, 4:10 PM UTC

msoad wrote: post #217

WorldMaker wrote: post #196

Earlier quoted context omitted.

Why would you nest try/catches? At worst you get try/catch parades: try { await thing1() } catch (e) { console.log(e) } try { await thing2() } catch (e) { console.log(e) } // ... and so forth ... That's still nothing like the pyramids you get in callback world.

That won't work because if thing1() throws you usually don't want to process to thing2 Take this for example: const response = await fetch('./api.json'); try { const json = await response.json(); console.log('YAY! JSON!', json); } catch (jsonParseError) { alert('damn it!'); } } catch(fetchError) { console.warn('this is not cool'); }

Okay, that's a fair counter-argument. My gut feeling is that's possibly one catch to many and as much as possible I'd want to try to merge the two catches/unifying the error response logic.

Another idea is that you could reformat to a "parade" try/catch by adding returns to the catch:

    try {
        const response = await fetch('./api.json')
    } catch (fetchError) {
        console.warn('this is not cool')
        return // Exit
    }
    try {
        const json = await response.json();
        console.log('YAY! JSON!', json);
    } catch (jsonParseError) {
        alert('damn it!');
    }

Obviously you'd need to move any code you'd want to run regardless of error up into the parent function or out into a wrapper function.

Re: JavaScript async/await implemented in V8

#223

Post by shimn » Wed, May 18, 2016, 7:15 PM UTC

lewisl9029 wrote: post #206

callahad wrote: post #173

Earlier quoted context omitted.

Consider looking at other languages. ClojureScript does a pretty good job at immutability, Elm is great for immutability + strong typing, and PureScript adds in Haskell's advanced type system (typeclasses, HKTs, etc.)

Definitely. ClojureScript is what I usually choose for my own projects, but the reality of the front-end job market is that JavaScript still dominates, so improvements to JavaScript itself will still have a significant impact on the lives of developers everywhere regardless of the existence of other compile-to-JS languages.

When I want to ensure strict immutability, I use an implementation of deepFreeze (https://github.com/jsdf/deep-freeze) that recursively calls Object.freeze() on all child properties. Obviously slower than strict browser support. Does ClojureScript rely on the Clojure compiler to ensure the properties aren't modified or is there some polyfill?

Re: JavaScript async/await implemented in V8

#224

Post by ilaksh » Thu, May 19, 2016, 1:45 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…

If you want a good solution to those types of problems in dynamic languages like ES6 then I think short functions and unit/functional tests are the best approach. Without that it is always going to be a bit challenging.

Having said that I have not seen worse stack traces with 'async/await. I think they are similar.

Re: JavaScript async/await implemented in V8

#225

Post by ilaksh » Thu, May 19, 2016, 1:48 AM UTC

z3t4 wrote: post #112

I can't see how wrapping everything in a promise and a try/catch, plus adding async/await is any easier then a callback.

You can write asynch code to look like synchronous code so you can follow the flow. You can also do things like await in for loops which is also the preferred flow a lot of times. You can use several async calls in order without making a pyramid and with much less code than promises or chaining callbacks across separate functions.

In short its cleaner code.

Re: JavaScript async/await implemented in V8

#226

Post by BinaryIdiot » Thu, May 19, 2016, 6:07 AM UTC

WorldMaker wrote: post #195

BinaryIdiot wrote: post #90

Earlier quoted context omitted.

Is there a reason you always wrap them? Even if it's awkward I tend to leave most platform APIs alone and treat them as special cases if I'm doing something, say, promises or messages.

Promises are much each to compose. Promise objects can be passed around and reused. (Multiple things can wait on the result of the same promise.) Code is much easier to read with flat .then() and .catch() chains, versus sometimes the "pyramid of doom" callbacks can create. Code is much, much easier to read with Promises when you can use async/await, and getting everything wrapped to promises now makes it that much so…

I get the why people want to use Promises in general but when they're used to simply wrap a standard node / browser call feels dirty to me because it changes what you expect it to return (e.g. a promise instead of whatever it normal returns).

I dunno I just don't like to give the impression I'm changing anything about how I'm accessing / using the standard library but I guess this is a bit subjective.

> versus sometimes the "pyramid of doom" callbacks can create

If you structure the code well you never run into this (callback soup is very overblown; if you find yourself in that position then someone screwed something up). But I get promises and async / await are nice :)

Re: JavaScript async/await implemented in V8

#227

Post by BinaryIdiot » Thu, May 19, 2016, 6:12 AM UTC

coldtea wrote: post #220

BinaryIdiot wrote: post #216

Earlier quoted context omitted.

It was simply a hypothetical but surely you can imagine a scenario where you either have to downgrade (perhaps a regression happens) or you simply have to target multiple versions. I've run into both situations multiple times in my career. Regardless yes you should use LTS but that's no excuse for going against semantic versioning. It should be labeled an alpha or beta if they don't want to change major versions for…

> It was simply a hypothetical but surely you can imagine a scenario where you either have to downgrade (perhaps a regression happens) Sure, but if you might have to downgrade, then simply don't write code that depends on 6.5 features. 6.5 can still run 6.1 code (feature wise), so you'll be alright. The only problem would be for people wanting to a) run 6.5, b) take advantage of newer, 6.5-only features, and THEN c)…

> Sure, but if you might have to downgrade, then simply don't write code that depends on 6.5 features.

Ah but see that's the rub. Hindsight is always 20/20. I've actually run into similar issues in the past. Ultimately if they're consistent with versions then it's not the biggest deal (because if you have an issue with 6.5 there is probably a good chance you have an issue with 6.1 as well) but with semantic versioning I always expect code written against the major version to always work across all minor versions unless it relied on some weird bug side effect.

It just seems really inconsistent to me.