12 ms·

Async/await support in Firefox

454 points by dallamaneni 10y ago

ilostmykeys 10y ago
Why would we want to mix async and sync behavior in one cognitive space? That seems counter evolutionary.
- pacomerh 10y ago
  Finer control?. Synced behavior is easier to understand and organize logically. You have the option to write it like a book and execute things "concurrently" (considering its really single threaded in JS).
  - ilostmykeys 10y ago
    Single threaded concurrency is not the same as synchronous/sequential execition. You and TC39 folks are telling us that mixing sync and async behavior in the same cognitive space is good? Amazing. Async handling should be in its own cognitive space.
notgood 10y ago
Great news. FYI Chrome will ship with async/await support[0] in the next stable version (55, so it's already on Chrome Canary). [0]https://bugs.chromium.org/p/v8/issues/detail?id=4483 https://bugs.chromium.org/p/v8/issues/detail?id=4483
- apaprocki 10y ago
  A giant shout-out to Igalia (Caitlin Potter!), who were instrumental in getting this implemented and shipped! https://blogs.igalia.com/compilers/2016/05/23/awaiting-the-future-of-javascript-in-v8/ https://blogs.igalia.com/compilers/2016/05/23/awaiting-the-f... This joins generators[1][2][3] (Andy Wingo) and arrow functions[4][5] (Adrian Perez de Castro, Andy Wingo) as examples of the community (read: not employees of Mozilla, Google, Apple, Microsoft) directly working on the engines to ship these features much sooner than they otherwise would be. (Surely they'd land eventually, but acceleration and cross-engine coordination greatly improves time-to-dev-market.) [1]: https://wingolog.org/archives/2013/05/08/generators-in-v8 https://wingolog.org/archives/2013/05/08/generators-in-v8 [2]: https://wingolog.org/archives/2013/10/07/es6-generators-and-iteration-in-spidermonkey https://wingolog.org/archives/2013/10/07/es6-generators-and-... [3]: https://wingolog.org/archives/2014/11/14/generators-in-firefox-now-twenty-two-times-faster https://wingolog.org/archives/2014/11/14/generators-in-firef... [4]: https://groups.google.com/forum/#!topic/v8-users/5FNvOv-kQY4 https://groups.google.com/forum/#!topic/v8-users/5FNvOv-kQY4 [5]: https://wingolog.org/archives/2015/06/18/arrow-functions-coming-to-chrome-45 https://wingolog.org/archives/2015/06/18/arrow-functions-com...
aboodman 10y ago
Biggest advance in JavaScript since ... I don't even know. XHR? Reasonable GC performance?
- greendragon 10y ago
  I've intentionally been keeping myself ignorant about async/await in JS until it's common enough I can consider using it natively without any great concern about cross browser compatibility. Why is everyone so excited for it? From the example it looks like a thin syntactic sugar layer over normal promises, what's so great about saving one level of indentation?
  - deleted 10y ago
    [deleted]
  - crooked-v 10y ago
    Ability to use asynchronous functions without pulling everything depending on them into a closure, which comes with a lot of baggage in how you have to structure things.
    - ghayes 10y ago
      Honest question, does async/await not create some variety of an implicit closure?
      - namuol 10y ago
        It's explicit, since the `async` keyword must only precede a function declaration. i.e.: async function () { ... } // or async () => { ... }
        foota 10y ago
        I believe they are discussing at the call site of an asynchronous function
      - 10y ago
pg_is_a_butt 10y ago
so, you're saying i should still wait? not sure you understand how this is supposed to work.
chinhodado 10y ago
Is there an article or book where the major "ways" of doing concurrency in different languages are explained and compared? E.g. thread process mutex semaphore etc. in Java et al, callback promise async await in JS, goroutine channel in Go, task async await plinq in C#, asyncio in Python, etc. It would be nice to have a general overview of these, what their pros and cons are and why.
- specialist 10y ago
  Pretty good survey. Seven Concurrency Models in Seven Weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in... https://www.amazon.com/Seven-Concurrency-Models-Weeks-Programmers/dp/1937785653 https://www.amazon.com/Seven-Concurrency-Models-Weeks-Progra...
  - tucif 10y ago
    I believe this one does not addresses async-await in any of its implementations directly, does it? But it looks pretty interesting to cover other concurrency models.
    - Matthias247 10y ago
      Actually it doesn't cover promises/tasks/rx or any other monadic stuff at all. The Clojure part also is probably not the most practical since it lacks core.async. However it's still a very good read and highly recommended. One reason is that it covers most of the concepts that make up a solid concurrent program (immutability, sharing data by communicating, ...).
- camwest 10y ago
  I found this a good resource: http://berb.github.io/diploma-thesis/ http://berb.github.io/diploma-thesis/
  - crudbug 10y ago
    I read this couple of days back, very well written.
Bahamut 10y ago
I have one major misgiving about async-await - the regression in needing to do a try-catch if one isn't isn't a test situation. This is a terrible syntax to have to write to handle this. That said, async functions also introduce a fundamental language shift in how one parses JS. One can now block execution to return a value, but no longer know if the innards of a function is blocking, which could mean that your function execution is blocked by an async execution. Instead of what one may know as async by looking at a promise or any other similar construct for handling async flow like observables, this will be the source of many bugs in developers' code as we shift in mindset, should this become popular. This would definitely improve readability of code written using continuation passing style though. Minus the awful try-catch, I'm not necessarily against async-await being the norm, but its broad effects on how async code will be written should be recognized, especially considering that it doesn't solve a fundamental issue like something like observables do.
- bryanh 10y ago
  You could always do something like: const maybe = await fetch(url).catch(err => err); But, I can understand that being a bit icky for some... but in a few cases it could make sense and is pretty concise: const hits = await cache.incr(key).catch(err => 0);
- gcommer 10y ago
  I view the use of try-catch as actually strictly an improvement... Before you had either 2-argument promise.then(...) or promise.catch(...), which were effectively the same as a try-catch (and in most promise libraries .then and .catch DID use try-catch under the hood), except they were now duplicated syntax for doing the same thing (handling exceptional cases). More likely you're arguing people shouldn't use 'exceptional situation' error handling as often as they do... but that's a separate argument. I think going from 2-3 syntaxes for the same thing to 1 syntax is strictly an improvement, especially since huge amounts of promise code silently swallow errors when people don't properly chain promises or handle the .catch case.
  - minitech 10y ago
    > and in most promise libraries .then and .catch DID use try-catch under the hood To catch thrown errors, not to implement the behaviour of transforming rejected promises.
tlrobinson 10y ago
I'm really looking forward to not having to debug my code compiled to state machines. Is there a good way to get Babel/Webpack to emit multiple versions of your code compiled with different features enabled, then load the right bundle?
- olalonde 10y ago
  I believe that's a goal of https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env. There are also a few manually crafted presets on npm which target a particular environment and EcmaScript version, e.g. https://github.com/blockai/babel-preset-eslatest-node6 https://github.com/blockai/babel-preset-eslatest-node6 (I'm the author).
- vcarl 10y ago
  There's a website, polyfill.io, that does browser sniffing and sends a minimal polyfill. The source is available under the MIT license[1], it shouldn't be a tremendous amount of work to set up a bunch of different builds for different features levels, with a server in front responsible for sending the correct bundle. [1]: https://github.com/Financial-Times/polyfill-service/blob/master/lib/UA.js https://github.com/Financial-Times/polyfill-service/blob/mas...
  - apaprocki 10y ago
    What you just described is what I always describe as the ideal web deployment system. Most of my dev is in C++, but I couldn't believe the inefficiency found in sniffing everything at runtime versus using what already exists to serve up different pre-compiled targets specifically optimized for all the major browser versions active in the field. It seems that products like this that span the dev workflow (compilation) / operational (sniffing server) gap are hard to get off the ground since many devs can't touch the ops side.
mark242 10y ago
Dear Javascript coders: If you wind up writing the word "await" in your codebase more than once, you're doing it wrong. You will quickly see how futures/promises wind up taking over all of your code. This is a very good thing. You shouldn't need to block, ever. Sincerely, Scala coders
- taeric 10y ago
  Dear Scala coders, Why have you decided to rewrite everything? Sincerely, Everyone else. (Obviously not JavaScript coders, sadly...) P.s. I can only hope you have a somewhat sane release story now.
- mehwoot 10y ago
  Am I missing something? Await doesn't block. It's just syntactic sugar for Promise.then(() => {}) without having to go down into callback hell. It makes code more readable and easier to write, but doesn't fundamentally change how it is working under the hood, as far as I am aware.
  - mark242 10y ago
    var txt = await read(); // This code is blocked until read() completes. console.log(txt);
    - kinkdr 10y ago
      It is in essence: read((err, txt) => { console.log(txt) }) Or read().then((txt) => console.log(txt)) Why is it bad?
    - olalonde 10y ago
      And how do you suggest to do that without "blocking"? :) Sure, you could use a stream but that isn't always possible or practical.
    - solipsism 10y ago
      That's not what blocking means.
jrvidal 10y ago
I am a JS programmer and I have mixed feelings about this. I am not entirely sold on the stuff that comes after async/await. In particular, I am curious to know what folks here think about cancelable promises [1] and the try...else block that might be introduced. Or about async iterators [2], where you can `yield await` stuff. [1] https://github.com/tc39/proposal-cancelable-promises https://github.com/tc39/proposal-cancelable-promises [2] https://github.com/tc39/proposal-async-iteration https://github.com/tc39/proposal-async-iteration
- k__ 10y ago
  Is this about the cancelation tokens they also want to force on observables?
  - jrvidal 10y ago
    Well, I was asking in general about all those new features that are in consideration: cancelation tokens, try...else, even the await.cancelToken meta-property [1]. It feels like a lot of baked-in syntactic support for a very specific pattern =/ [1] https://github.com/tc39/proposal-cancelable-promises/blob/master/Cancel%20Tokens.md https://github.com/tc39/proposal-cancelable-promises/blob/ma...
awalGarg 10y ago
Note that async functions always return native promises. So if you like your fast or sugary promise libraries, you can't make async functions return those promises. You are stuck with the native promises, which, as of now, are pretty slow in almost all engines in comparison to the heavily optimized promise library bluebird. I guess we should just hope that engines will optimize their own promise implementations. This might not matter much in front-end apps, but absolutely does for Node apps. Other than that, I believe it is time JS gets: 1. An actually useful try/catch (with pattern matching on the catched errors) 2. Standard stack traces across all engines Those two will really help async/await.
- KwanEsq 10y ago
  >I guess we should just hope that engines will optimize their own promise implementations. Firefox/Spidermonkey have just ported their Promises completely to C++ [1] which will help performance and enable future optimisations. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1313049 https://bugzilla.mozilla.org/show_bug.cgi?id=1313049
  - bzbarsky 10y ago
    The funny part is that they _used_ to be completely in C++ (as part of Gecko, not SpiderMonkey). Then they were rewritten to be part of SpiderMonkey, and various bits were made self-hosted in the process. This turned out to be slower than doing it all in C++, for various reasons, some of which might be Gecko-specific (e.g. support for security wrappers). But in general, optimizing promises as specified in ES6 is _really_ hard. There's all sorts of work that the spec says should be done which is typically unnecessary (for example, did you know that every time you resolve a Promise with another Promise, that causes creation of a _third_ Promise that no one cares about) but can be observed from script in various ways (e.g. by messing with @@species) so are very hard to optimize out. Promises are also very gc-intensive as specified.... This is one of those cases (iterators being the other poster child) where the usual "yeah, people will just write complicated enough engines with complicated enough JITs to make this all perform OK enough" attitude of the ECMA committee is a bit annoying.
- 10y ago
fergie 10y ago
Still not entirely sure what the big win with async/await is. Is it just a readability thing? Is there one "killer" case that demonstrates its superiority over callbacks?
- Yaggo 10y ago
  It's basically a fancy (but more limited) syntax for promise, with the same advantages.
- _pdp_ 10y ago
  I agree to some degree but at the end of the day it is a programming style. I personally prefer the functional approach with bound methods to avoid callback hell, improve readability and ensure there is minimal amount of memory leaking. That being said, async/await makes callback programming easier so it is another tool which may come handy in the situations where you really need it.
- pjmlp 10y ago
  Yes, you can match async/wait with generators thus using them for monad computations in Javascript. Think of async as return and await as bind.
  - fergie 10y ago
    "you can match async/wait with generators thus using them for monad computations in Javascript" I hear the words you are saying, I just cant visualise the concept. Could you ELI5, or post an example?
    - pjmlp 10y ago
      Yes, check Bodil Stokke's presentation, The Miracle of Generators, at GOTO 2016. https://www.youtube.com/watch?v=6mCkLZ0cwAI https://www.youtube.com/watch?v=6mCkLZ0cwAI
      - fergie 10y ago
yladiz 10y ago
Am I alone in the boat that feels that the way that async/await is implemented in JS is a little wonky? I kind of prefer that you can do `await asyncFunc(...)` without having to denote the function itself as `async`, but I don't like that you can just call the `asyncFunc` without `await` and it would still potentially do something. In Python, when you `await` something, it actually runs the code, whereas running the function by itself just returns a Future that hasn't been started. I feel like it's less difficult to shoot yourself in the foot with Python's implementation, because you know that if you're calling an asynchronous function, you have to `await` it or it won't work and won't have side effects. In JS, you could call the async function without awaiting it and it could have side effects which could produce subtle bugs that aren't easy to find.

454 points by dallamaneni 10y ago

ilostmykeys 10y ago

Why would we want to mix async and sync behavior in one cognitive space? That seems counter evolutionary.

pacomerh 10y ago
Finer control?. Synced behavior is easier to understand and organize logically. You have the option to write it like a book and execute things "concurrently" (considering its really single threaded in JS).
- ilostmykeys 10y ago
  Single threaded concurrency is not the same as synchronous/sequential execition. You and TC39 folks are telling us that mixing sync and async behavior in the same cognitive space is good? Amazing. Async handling should be in its own cognitive space.

notgood 10y ago

Great news. FYI Chrome will ship with async/await support[0] in the next stable version (55, so it's already on Chrome Canary). [0]https://bugs.chromium.org/p/v8/issues/detail?id=4483 https://bugs.chromium.org/p/v8/issues/detail?id=4483

apaprocki 10y ago
A giant shout-out to Igalia (Caitlin Potter!), who were instrumental in getting this implemented and shipped! https://blogs.igalia.com/compilers/2016/05/23/awaiting-the-future-of-javascript-in-v8/ https://blogs.igalia.com/compilers/2016/05/23/awaiting-the-f... This joins generators[1][2][3] (Andy Wingo) and arrow functions[4][5] (Adrian Perez de Castro, Andy Wingo) as examples of the community (read: not employees of Mozilla, Google, Apple, Microsoft) directly working on the engines to ship these features much sooner than they otherwise would be. (Surely they'd land eventually, but acceleration and cross-engine coordination greatly improves time-to-dev-market.) [1]: https://wingolog.org/archives/2013/05/08/generators-in-v8 https://wingolog.org/archives/2013/05/08/generators-in-v8 [2]: https://wingolog.org/archives/2013/10/07/es6-generators-and-iteration-in-spidermonkey https://wingolog.org/archives/2013/10/07/es6-generators-and-... [3]: https://wingolog.org/archives/2014/11/14/generators-in-firefox-now-twenty-two-times-faster https://wingolog.org/archives/2014/11/14/generators-in-firef... [4]: https://groups.google.com/forum/#!topic/v8-users/5FNvOv-kQY4 https://groups.google.com/forum/#!topic/v8-users/5FNvOv-kQY4 [5]: https://wingolog.org/archives/2015/06/18/arrow-functions-coming-to-chrome-45 https://wingolog.org/archives/2015/06/18/arrow-functions-com...

aboodman 10y ago

Biggest advance in JavaScript since ... I don't even know. XHR? Reasonable GC performance?

greendragon 10y ago
I've intentionally been keeping myself ignorant about async/await in JS until it's common enough I can consider using it natively without any great concern about cross browser compatibility. Why is everyone so excited for it? From the example it looks like a thin syntactic sugar layer over normal promises, what's so great about saving one level of indentation?
- deleted 10y ago
  [deleted]
- crooked-v 10y ago
  Ability to use asynchronous functions without pulling everything depending on them into a closure, which comes with a lot of baggage in how you have to structure things.
  - ghayes 10y ago
    Honest question, does async/await not create some variety of an implicit closure?
    - namuol 10y ago
      It's explicit, since the `async` keyword must only precede a function declaration. i.e.: async function () { ... } // or async () => { ... }
      - foota 10y ago
        I believe they are discussing at the call site of an asynchronous function
    - 10y ago

pg_is_a_butt 10y ago

so, you're saying i should still wait? not sure you understand how this is supposed to work.

chinhodado 10y ago

Is there an article or book where the major "ways" of doing concurrency in different languages are explained and compared? E.g. thread process mutex semaphore etc. in Java et al, callback promise async await in JS, goroutine channel in Go, task async await plinq in C#, asyncio in Python, etc. It would be nice to have a general overview of these, what their pros and cons are and why.

specialist 10y ago
Pretty good survey. Seven Concurrency Models in Seven Weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in... https://www.amazon.com/Seven-Concurrency-Models-Weeks-Programmers/dp/1937785653 https://www.amazon.com/Seven-Concurrency-Models-Weeks-Progra...
- tucif 10y ago
  I believe this one does not addresses async-await in any of its implementations directly, does it? But it looks pretty interesting to cover other concurrency models.
  - Matthias247 10y ago
    Actually it doesn't cover promises/tasks/rx or any other monadic stuff at all. The Clojure part also is probably not the most practical since it lacks core.async. However it's still a very good read and highly recommended. One reason is that it covers most of the concepts that make up a solid concurrent program (immutability, sharing data by communicating, ...).
camwest 10y ago
I found this a good resource: http://berb.github.io/diploma-thesis/ http://berb.github.io/diploma-thesis/
- crudbug 10y ago
  I read this couple of days back, very well written.

Bahamut 10y ago

I have one major misgiving about async-await - the regression in needing to do a try-catch if one isn't isn't a test situation. This is a terrible syntax to have to write to handle this. That said, async functions also introduce a fundamental language shift in how one parses JS. One can now block execution to return a value, but no longer know if the innards of a function is blocking, which could mean that your function execution is blocked by an async execution. Instead of what one may know as async by looking at a promise or any other similar construct for handling async flow like observables, this will be the source of many bugs in developers' code as we shift in mindset, should this become popular. This would definitely improve readability of code written using continuation passing style though. Minus the awful try-catch, I'm not necessarily against async-await being the norm, but its broad effects on how async code will be written should be recognized, especially considering that it doesn't solve a fundamental issue like something like observables do.

bryanh 10y ago
You could always do something like: const maybe = await fetch(url).catch(err => err); But, I can understand that being a bit icky for some... but in a few cases it could make sense and is pretty concise: const hits = await cache.incr(key).catch(err => 0);
gcommer 10y ago
I view the use of try-catch as actually strictly an improvement... Before you had either 2-argument promise.then(...) or promise.catch(...), which were effectively the same as a try-catch (and in most promise libraries .then and .catch DID use try-catch under the hood), except they were now duplicated syntax for doing the same thing (handling exceptional cases). More likely you're arguing people shouldn't use 'exceptional situation' error handling as often as they do... but that's a separate argument. I think going from 2-3 syntaxes for the same thing to 1 syntax is strictly an improvement, especially since huge amounts of promise code silently swallow errors when people don't properly chain promises or handle the .catch case.
- minitech 10y ago
  > and in most promise libraries .then and .catch DID use try-catch under the hood To catch thrown errors, not to implement the behaviour of transforming rejected promises.

tlrobinson 10y ago

I'm really looking forward to not having to debug my code compiled to state machines. Is there a good way to get Babel/Webpack to emit multiple versions of your code compiled with different features enabled, then load the right bundle?

olalonde 10y ago
I believe that's a goal of https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env. There are also a few manually crafted presets on npm which target a particular environment and EcmaScript version, e.g. https://github.com/blockai/babel-preset-eslatest-node6 https://github.com/blockai/babel-preset-eslatest-node6 (I'm the author).
vcarl 10y ago
There's a website, polyfill.io, that does browser sniffing and sends a minimal polyfill. The source is available under the MIT license[1], it shouldn't be a tremendous amount of work to set up a bunch of different builds for different features levels, with a server in front responsible for sending the correct bundle. [1]: https://github.com/Financial-Times/polyfill-service/blob/master/lib/UA.js https://github.com/Financial-Times/polyfill-service/blob/mas...
- apaprocki 10y ago
  What you just described is what I always describe as the ideal web deployment system. Most of my dev is in C++, but I couldn't believe the inefficiency found in sniffing everything at runtime versus using what already exists to serve up different pre-compiled targets specifically optimized for all the major browser versions active in the field. It seems that products like this that span the dev workflow (compilation) / operational (sniffing server) gap are hard to get off the ground since many devs can't touch the ops side.

mark242 10y ago

Dear Javascript coders: If you wind up writing the word "await" in your codebase more than once, you're doing it wrong. You will quickly see how futures/promises wind up taking over all of your code. This is a very good thing. You shouldn't need to block, ever. Sincerely, Scala coders

taeric 10y ago
Dear Scala coders, Why have you decided to rewrite everything? Sincerely, Everyone else. (Obviously not JavaScript coders, sadly...) P.s. I can only hope you have a somewhat sane release story now.
mehwoot 10y ago
Am I missing something? Await doesn't block. It's just syntactic sugar for Promise.then(() => {}) without having to go down into callback hell. It makes code more readable and easier to write, but doesn't fundamentally change how it is working under the hood, as far as I am aware.
- mark242 10y ago
  var txt = await read(); // This code is blocked until read() completes. console.log(txt);
  - kinkdr 10y ago
    It is in essence: read((err, txt) => { console.log(txt) }) Or read().then((txt) => console.log(txt)) Why is it bad?
  - olalonde 10y ago
    And how do you suggest to do that without "blocking"? :) Sure, you could use a stream but that isn't always possible or practical.
  - solipsism 10y ago
    That's not what blocking means.

jrvidal 10y ago

I am a JS programmer and I have mixed feelings about this. I am not entirely sold on the stuff that comes after async/await. In particular, I am curious to know what folks here think about cancelable promises [1] and the try...else block that might be introduced. Or about async iterators [2], where you can `yield await` stuff. [1] https://github.com/tc39/proposal-cancelable-promises https://github.com/tc39/proposal-cancelable-promises [2] https://github.com/tc39/proposal-async-iteration https://github.com/tc39/proposal-async-iteration

k__ 10y ago
Is this about the cancelation tokens they also want to force on observables?
- jrvidal 10y ago
  Well, I was asking in general about all those new features that are in consideration: cancelation tokens, try...else, even the await.cancelToken meta-property [1]. It feels like a lot of baked-in syntactic support for a very specific pattern =/ [1] https://github.com/tc39/proposal-cancelable-promises/blob/master/Cancel%20Tokens.md https://github.com/tc39/proposal-cancelable-promises/blob/ma...

awalGarg 10y ago

Note that async functions always return native promises. So if you like your fast or sugary promise libraries, you can't make async functions return those promises. You are stuck with the native promises, which, as of now, are pretty slow in almost all engines in comparison to the heavily optimized promise library bluebird. I guess we should just hope that engines will optimize their own promise implementations. This might not matter much in front-end apps, but absolutely does for Node apps. Other than that, I believe it is time JS gets: 1. An actually useful try/catch (with pattern matching on the catched errors) 2. Standard stack traces across all engines Those two will really help async/await.

KwanEsq 10y ago
>I guess we should just hope that engines will optimize their own promise implementations. Firefox/Spidermonkey have just ported their Promises completely to C++ [1] which will help performance and enable future optimisations. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1313049 https://bugzilla.mozilla.org/show_bug.cgi?id=1313049
- bzbarsky 10y ago
  The funny part is that they _used_ to be completely in C++ (as part of Gecko, not SpiderMonkey). Then they were rewritten to be part of SpiderMonkey, and various bits were made self-hosted in the process. This turned out to be slower than doing it all in C++, for various reasons, some of which might be Gecko-specific (e.g. support for security wrappers). But in general, optimizing promises as specified in ES6 is _really_ hard. There's all sorts of work that the spec says should be done which is typically unnecessary (for example, did you know that every time you resolve a Promise with another Promise, that causes creation of a _third_ Promise that no one cares about) but can be observed from script in various ways (e.g. by messing with @@species) so are very hard to optimize out. Promises are also very gc-intensive as specified.... This is one of those cases (iterators being the other poster child) where the usual "yeah, people will just write complicated enough engines with complicated enough JITs to make this all perform OK enough" attitude of the ECMA committee is a bit annoying.
10y ago

fergie 10y ago

Still not entirely sure what the big win with async/await is. Is it just a readability thing? Is there one "killer" case that demonstrates its superiority over callbacks?

Yaggo 10y ago
It's basically a fancy (but more limited) syntax for promise, with the same advantages.
_pdp_ 10y ago
I agree to some degree but at the end of the day it is a programming style. I personally prefer the functional approach with bound methods to avoid callback hell, improve readability and ensure there is minimal amount of memory leaking. That being said, async/await makes callback programming easier so it is another tool which may come handy in the situations where you really need it.
pjmlp 10y ago
Yes, you can match async/wait with generators thus using them for monad computations in Javascript. Think of async as return and await as bind.
- fergie 10y ago
  "you can match async/wait with generators thus using them for monad computations in Javascript" I hear the words you are saying, I just cant visualise the concept. Could you ELI5, or post an example?
  - pjmlp 10y ago
    Yes, check Bodil Stokke's presentation, The Miracle of Generators, at GOTO 2016. https://www.youtube.com/watch?v=6mCkLZ0cwAI https://www.youtube.com/watch?v=6mCkLZ0cwAI
    - fergie 10y ago

yladiz 10y ago

Am I alone in the boat that feels that the way that async/await is implemented in JS is a little wonky? I kind of prefer that you can do `await asyncFunc(...)` without having to denote the function itself as `async`, but I don't like that you can just call the `asyncFunc` without `await` and it would still potentially do something. In Python, when you `await` something, it actually runs the code, whereas running the function by itself just returns a Future that hasn't been started. I feel like it's less difficult to shoot yourself in the foot with Python's implementation, because you know that if you're calling an asynchronous function, you have to `await` it or it won't work and won't have side effects. In JS, you could call the async function without awaiting it and it could have side effects which could produce subtle bugs that aren't easy to find.