16 ms·

JavaScript async/await implemented in V8

• dkuznetsov 10y ago
  I like how it rhymes.
  • deleted 10y ago
    [deleted]
• dmihal 10y ago
  Here's a simple guide to async/await. https://www.twilio.com/blog/2015/10/asyncawait-the-hero-javascript-deserved.html https://www.twilio.com/blog/2015/10/asyncawait-the-hero-java...
  • sotojuan 10y ago
    Eddie Zaneski is an awesome and friendly guy! Here's another awesome article on it: http://amasad.me/2015/10/31/javascript-async-functions-for-easier-concurrent-programming/ http://amasad.me/2015/10/31/javascript-async-functions-for-e...
• tanto 10y ago
  The moment I started using async await (with babel) combined with the new fetch API so many libraries got obsolete. Getting data is as easy as: async function main () { try { const res = await fetch('https://api.github.com/orgs/facebook'); const json = await res.json(); console.log(json); } catch (e) { // handle error } } So I am quite happy when this lands in modern browsers asap.
  • startling 10y ago
    Is the syntax composable? Can I do const json = await (await fetch(https://api.github.com/orgs/facebook')).json(); or do I have to name it?
    • bsou 10y ago
      yeah that works, your statement is fine
      • startling 10y ago
        nice, thanks!
    • smilekzs 10y ago
      What you asked for is whether `await` is idempotent. No it isn't. The "argument" to `await` is a Promise, and the "return value" of it is the resolved value of the Promise (i.e. `Promise#then`). EDIT: I missed the `.json()` part, but I suppose it doesn't return a Promise, no?
      • tanto 10y ago
        actually .json() returns a Promise. The first fetch only returns HTTP status code and some other details. The content itself is streamed. You can also access the stream if you want too. In general you would rather just call .json() and get the parsed data. The fetch function can for example also be used to get images. There you would use .blob() and assign that to an image.src with URL.createObjectURL(blob); See here: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
      • startling 10y ago
        This is totally not what I'm asking, thanks.
    • dvlsg 10y ago
      You probably can, but you may as well just do this instead: const json = await fetch('https://api.github.com/orgs/facebook').then(res => res.json());
      • ludamad 10y ago
        I think the await code is more explicit, whereas a callback is somewhat ambiguous
  • ludamad 10y ago
    With this natively in V8 the debug experience ought to be much better than now, too
  • foota 10y ago
    Is using async/await through babel a good idea? When I last looked at it I thought it was using a busy loop which didn't seem like such a great idea to use in shipping code.
    • tlrobinson 10y ago
      It's fine. It transforms async functions into a state machine.
    • nostrademons 10y ago
      It's okay but clumsy. It's a state machine, not a busy loop, but the compiled code is a lot more verbose than the input code (and so you pay a latency penalty on the client). The developer experience is also sub-par: you'll get regenerator stack frames in any of your stack traces, and it interacts poorly with babel-watch. You can do it, it's not insane, but native async/await will be much, much nicer.
      • tlrobinson 10y ago
        Can you elaborate on "it interacts poorly with babel-watch."?
        • nostrademons 10y ago
          IIRC under babel-watch it required me to include babel-polyfill at the top of my main script, but under babel-node it prevented me from including babel-polyfill at the top of my main script. (babel-polyfill has a check so that it can only be required once, and errors out otherwise.) That meant I needed to keep commenting/uncommenting that line when I wanted to debug things. There were also cases where I wasn't sure if babel-watch was reloading dependencies properly if I used async code in a file, which is why I had to keep switching to babel-node or running the code through babel and inspecting the generated code to debug. Overall, it just felt very new and unpolished (which I guess it was...I was working with it around March, so babel-watch was < 1 month old and babel async/await was about 2-3 months at the time) to be relying on all the time.
      • deleted 10y ago
  • viperscape 10y ago
    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.
    • bb85 10y ago
      The great thing about let and const, for me, is that it gives you crucial information about variables without having to look further down. const should be the default, and if you're going to reassign it, then use let. In most code, you'll use const on the vast majority of variables, and it'll make let assignments stick out, which helps a lot when you're browsing the code or refactoring.
      • spraak 10y ago
        This right here. One of my friends (a more experienced developer) told me at coffee one day, "I use const for everything" which really stuck with me. It really helps make it clear if you need a mutation to have let stand out.
        • rpastuszak 10y ago
          However, it's worth noting that using const doesn't make variables immutable. It only protects them of being reassigned: const val = 'a'; val = 'b'; // TypeError const obj = { val: 'a' }; obj.val = 'b'; // This line will still work. obj = { val: 'b' }; // TypeError
          • dcherman 10y ago
            Yep. In those cases, I still prefer let personally even though I know the variable itself will not be re-assigned, kind of as an indicator that I expect the referenced object to be mutated.
            • candu 10y ago
  • dfischer 10y ago
    What do you use for the new fetch api on node?
    • mikeryan 10y ago
      I don't use it on Node but this syntax is great on react native.
    • pitaj 10y ago
      Probably [node-fetch](https://www.npmjs.com/package/node-fetch https://www.npmjs.com/package/node-fetch)
    • ascagnel_ 10y ago
      node-fetch is one option, but I go with isomorphic-fetch[0] (since it can be run client-side via Babel). [0] https://github.com/matthew-andrews/isomorphic-fetch https://github.com/matthew-andrews/isomorphic-fetch
      • danielstocks 10y ago
        fyi isomorphic-fetch is just a universal wrapper around node-fetch and github-fetch
  • tomp 10y ago
    Can anyone point to a good explanation why this is preferable to cooperative threads (coroutines)? I.e. the above code could easily be written as function main() { try { const res = fetch('https://api.github.com/orgs/facebook'); // yield here const json = res.json(); // yield here console.log(json); } catch (e) { // handle error } } and the runtime would automatically yield this coroutine and let other coroutines run whenever some call blocks. I guess the only realy difference would be that I would make `await` (and `async`) implicit, similar to how exceptions are handled implicitly in the above snippet (i.e. we don't annotate functions as `throwing` and we don't use an `attempt` statement (analogous to `await`) when calling `throwing` functions). Edit: Reading various articles, the best explanation is that since the single-threaded nature of JavaScript makes synchronisity implicit (i.e. all code is run in an implicit transaction), it has to make asynchronisity explicit. The alternative would be to have coroutines/fibres (implicit asynchronisity), but with explicit `atomic` blocks (for synchronisity). C# doesn't provide any synchronisity guarantees, so I guess the motivations there were different (it's really hard (impossible?) to implement fibres efficiently, and even harder to allow for native code interoperability).
    • turblety 10y ago
      It might be something to do with backwards compatibility.
      • tomp 10y ago
        What do you mean? Edit: I mean, can you give any examples of how old code would be broken by implementing something like this?
    • amelius 10y ago
      Perhaps this is the reason: Is it possible to have a yield inside a called function (i.e., not the generator function itself)? Last time I checked this was not allowed (?) Anyway, if so, I would strongly prefer this over a async/await construct, which is less general.
  • Kiro 10y ago
    Why do you need to put await before res.json?
    • tomelders 10y ago
      Someone correct me if I'm wrong here, this is just my hunch - but according to the fetch spec, res.json returns a promise, which are async. I'm assuming so you have the chance to handle errors as a result of malformed JSON.
      • thomasahle 10y ago
        Promises are used for catching errors?
        • onestone 10y ago
          Yes.
    • jwmerrill 10y ago
      At the time that the request resolves, it has received and processed the response headers, but it may still be receiving the response body (which is represented as a stream). All the body representations (like .text() or .json()) need to wait until the body has arrived before they can resolve. https://fetch.spec.whatwg.org/#concept-body-consume-body https://fetch.spec.whatwg.org/#concept-body-consume-body
  • deleted 10y ago
    [deleted]
• hoodoof 10y ago
  This news is almost as important as the rest of ES2015 being implemented in Webkit. async/await is the final piece in the puzzle of providing real solutions to callback hell in JavaScript.
  • ihsw 10y ago
    I am willing to admit that async/await is a bridge between the Node and .Net communities -- surmounting this means we are that much closer to literally doubling the developer pool for either sections of the community.
    • mkoryak 10y ago
      how so? I like the JS async/await a lot, but you couldnt pay me to write .net I personally don't know many devs who would choose to learn a new lang because of a feature (assuming that they didn't want to learn it before it existed)
      • Rapzid 10y ago
        Why would it be futile for someone to offer you money for writing .net code(and to be clear I'm assuming we are talking about csharp).
      • SomeCallMeTim 10y ago
        I held my nose when I was forced to write JavaScript until I learned about async/await. I came from a language that can do this kind of thing implicitly using coroutines (i.e., I could write imperative code that would pause on a network request and resume afterwards). Have to wade through callback hell -- even with Promises -- was a serious step down. With async/await being explicit, combined with functionality like Promise.all(), this is actually a better solution than I had before, because I can spawn a dozen queries at once and wait for them all to complete before I continue. I've used that to good advantage already once with an await Promise.all(...) call, and the patterns are so easy to follow that it brings tears to my eyes. Or I can inject more traditional callbacks when the logic would be easier (or when it would allow several simultaneous calls to complete), which does happen from time to time. As to whether I'd learn a new language because of it: I'm considering learning Elixir because of even stronger guarantees [1], actually, so yes, I would. [1] Apparently in addition to being able to write code using light threads like this, you can also put a cap on how long the VM will run code, so if some idiot developer puts a loop in the code that doesn't return control enough, instead of destroying your UI experience it will just pause that loop and resume the main loop. Still have yet to try it though.
• rattray 10y ago
  > [esnext] prototype runtime implementation for async functions Well, it claims to be a prototype. Can anyone from the team comment? Quite exciting in any case!
  • deleted 10y ago
    [deleted]
• andrewstuart2 10y ago
  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 make tons of sense either. I've done a lot of async and I've never needed anything beyond Q that I can recall. This feels like a step toward added confusion rather than language unity. Much like the majority of of ES6 feels to me: bolted-on features from popular synchronous languages that themselves are only now adding features like lambdas. I don't want to write faux-event-driven code that hides the eventedness beneath native abstractions. And I definitely don't want to work with developers, new and old, trying to learn the language and whether/when they should use async/await, promises, or fall back to an es5 library or on* event handlers. I want developers who grok functional event-driven code with contextual closures.
  • tanto 10y ago
    > (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 library for this is quite nice.
    • dvlsg 10y ago
      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.json()` portion immediately, instead of waiting for both responses to return before continuing.
• ihsw 10y ago
  Realistically does this mean we will see async/await in node-v7.0?
  • coldtea 10y ago
    Probably in an upcoming Node 6 -- they do update the running version with the latest v8 releases IIRC.
    • BinaryIdiot 10y ago
      That seems like a mistake to me. That would mean code that runs perfectly under, say, 6.5 would not run on 6.1. It should most certainly be a 7.x release.
      • sublimino 10y ago
        This is intentional - it's a feature, not a breaking change, although the docs do identify a greater possibility of regressions until LTS. From https://nodejs.org/en/blog/release/v6.0.0/ https://nodejs.org/en/blog/release/v6.0.0/ > The general rule for deciding which version of Node.js to use is: > ... > - Upgrade to Node.js v6 if you have the ability to upgrade versions quickly and want to play with the latest features as they arrive. > Note that while v6 will eventually transition into LTS, until it does, we will still be actively landing new features (semver-minor). This means that there is an increased chance for regressions to be introduced..
      • coldtea 10y ago
        For stability one should be using the LTS release. And why would one downgrade from 6.5 to 6.1? If they code for 6.1 and want to not use LTS and to keep 6.1 installations around, then they should not use 6.5 features.
        • BinaryIdiot 10y ago
          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 breaking feature additions.
• ht85 10y ago
  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 and enjoyable fashion. I find async/await much more appealing when coding, but I'm worried about quality of life when hardcore debugging, as in my current project it can make me waste hours at a time when something if completely fringe happens.
  • jeswin 10y ago
    I have some medium/large projects using async-await. There are 2 ways to transpile async-await. a) Default, with regenerator, transpiles it to ES5 b) If your env supports generators (like Node, or newer browsers), you can use async-to-generator plugin. Regenerator gives you unreadable code, but it will run everywhere. async-to-generator gives you (relatively) readable code. Source maps support has improved a lot, and you can choose to see only your original code while debugging. You'd be setting breakpoints on your code instead of transpiled code. So you should be fine whether you're using regenerator or async-to-generator. There might be corner cases (very rare) depending on your env; in which case if you're using regenerator you might need to switch to async-to-generator to find the bug. Source maps work well with node-inspector. If you'd like to see better stack traces in say "mocha" tests (or other test framework), use https://github.com/evanw/node-source-map-support https://github.com/evanw/node-source-map-support. Overall, the developer experience is now pretty good. Thanks to all the work that's gone into the tooling.
  • deleted 10y ago
    [deleted]
  • ilaksh 10y ago
    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.
• avodonosov 10y ago
  what's the point of explicitly declaring functions "async", and then explicitly saying "await". IMHO all this could be done automatically by language.
  • spriggan3 10y ago
    > what's the point of explicitly declaring functions "async", and then explicitly saying "await". IMHO all this could be done automatically by language. Not without Fibers. Javascript doesn't have Fibers though there an implementation in Nodejs. What it changes is that you don't have to rely on yet another library anymore to get the behavior people mostly use yield for. I'm talking about co/thunk . While it doesn't solve the red/blue function issue [1], it makes writing async code a bit less tedious. At the end of the day it will force everybody to return promises from async functions, rather than requiring callbacks,which is a good thing. [1] : http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
  • wwwtyro 10y ago
    I'm sure there's good reason, but I have the same question. I also don't understand the need to use promises in the construct. I'd love some clarity here.
    • mkoryak 10y ago
      async/await is just sugar around promises. when you await something, that something must be a promise. coroutines are used to make your code appear to execute without a need for a callback, and in order to create a coroutine one must wrap the function doing the awaiting in a generator. now, I am assuming (perhaps incorrectly) that the async keyoword marks the function for wrapping, and await lets you know where the yields should go. or something like that :) of course, now thats its all native, I have no idea any more
  • perrin4869 10y ago
    how would that work?
  • 10y ago
• lath 10y ago
  In the meantime there's the co library which provides the next best thing using yield.
  • 131hn 10y ago
    And a swifter way to handle legacy callback (using thunks). Co is _great_ and work today (even in browser)
• jdgiese 10y ago
  Super excited to start seeing async/await in some of the browsers. Async/await makes certain function decorator patterns even more useful, e.g. http://innolitics.com/10x/javascript-decorators-for-promise-returning-functions/ http://innolitics.com/10x/javascript-decorators-for-promise-...
• md224 10y ago
  Looking at Kangax's support table: http://kangax.github.io/compat-table/esnext/#test-async_functions http://kangax.github.io/compat-table/esnext/#test-async_func... Apparently Microsoft Edge seems to have been the first browser to implement it... good job Microsoft!
• deleted 10y ago
  [deleted]
• bigtones 10y ago
  Thank you to Microsoft and Anders Hejlsberg for inventing Async/Await (and to F# for the original inspiration) https://en.wikipedia.org/wiki/Futures_and_promises https://en.wikipedia.org/wiki/Futures_and_promises
  • Lx1oG-AWb6h_ZG0 10y ago
    async/await as we know it actually came from Midori's C# dialect, which indeed was inspired from F#: http://joeduffyblog.com/2015/11/19/asynchronous-everything/ http://joeduffyblog.com/2015/11/19/asynchronous-everything/ (Although, just to be pedantic, the concept of futures is way older than F#. Alice's syntax, for example, is pretty close)
    • MichaelGG 10y ago
      The nice part about F#'s async implementation is that it was purely a library. I wish languages aimed at allowing developers to build things for the language, rather than providing more compiler built-ins. Making it extensible is more elegant (though I understand it might be easier to optimize perf).
      • barrkel 10y ago
        Integrated features are easier to tool and provide good diagnostics for. It's nice to have enough expressiveness to model monadic computations without too much syntactic overhead - and monads are usually enough, since they hand blobs of user code to the library to be composed as necessary - but debugging a reshuffled graph of closures is no picnic.
• johnhenry 10y ago
  I'm definitely rooting for the feature to be included in the spec as soon as possible, but I'm a little weary when features are added to the engine before being standardized. Object.observe, anyone?
  • sodatea 10y ago
    The only reason that async/await hasn't been included in standard is because there were not enough implementations.
  • WorldMaker 10y ago
    Things should be clearer now that the "Stage Process" [1] is more transparent. Object.observe made it only as far as Stage 2 ("Draft"), but async/await has already pushed on to Stage 3 ("Candidate"), making it much more likely it will hit Stage 4 ("Final") just as soon as a plurality of web browsers support it. (...and as soon as it hits Stage 4 it will be included in that years final spec, under the new annual review process.) [1] https://tc39.github.io/process-document/ https://tc39.github.io/process-document/
• xanderjanz 10y ago
  From all my research, I feel like Promises end up making better code than async await. Am I the only one who thinks that? Like, what's the equivalent of Promise.all with async/await? And how do tou do stuff synchronously after kicking off an async process?
  • bsimpson 10y ago
    I haven't written any async/await code yet, but since it's just sugar over promises, wouldn't you just do "await Promise.all(...)"?
    • dvlsg 10y ago
      Yup. Promise.all() returns a new Promise which settles after every Promise in the provided array has settled (or throws after one of the provided Promises throws).
  • skrebbel 10y ago
    I'm not sure you fully grok async/await then. Thing is, using async/await means using promises. You can't use async/await without promises. An async function returns a promise. Always. (in a way, `async` can be seen as something of a type annotation). If you want to use async/await with something that's asynchronous but not Promise based, you'll first need to convert it into a promise before you can async/await it. This is actually very elegant in my opinion: instead of proposing yet another way to do asynchronicity in JS, async/await fully embraces Promises, which you already know. Of course, this means that async/await also has all of Promise's downsides. For example, you can only resolve a promise once, so neither Promises now async/await make dealing with streams of asynchonous events any easier.
    • jdc0589 10y ago
      I don't see that as a downside. Callbacks make sense for the pipelining portion of async streams. I usually wrap things up such that i set up my callback/event based stream pipeline, and then have a promise that gets resolves on completion/end. That way your stream code is 100% normal callbacks, and you still have promises/async/await for overall flow control.
• jcoffland 10y ago
  The one extra diff I would really like to see in that list is some documentation. The V8 docs have always been too sparse.
• z3t4 10y ago
  I can't see how wrapping everything in a promise and a try/catch, plus adding async/await is any easier then a callback.
  • msoad 10y ago
    Exactly! When you count for nested try/catchs you see no significant improvement
    • WorldMaker 10y ago
      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.
      • zzzcpan 10y ago
        "Pyramids" are not that useful for complex flows, just as synchronous-looking code, but for something as simple as your example they are equivalent in complexity, maybe even less complex, because they don't have additional implicit behavior introduced by async/await. Still, worlds better, than CSP with channels.
        • WorldMaker 10y ago
          async/await ends up being the less complex thing, my "simple" example is an extreme that sometimes but rarely happens. When was the last time you saw that in synchronous code? It happens, certainly but the synchronous default is to only handle what you can handle and then pass everything else back up the chain. The asynchronous default with async/await is the same, and you can rely on default error propagation in the natural default case: async function doTheThing() { await thing1() await thing2() } That just works, if there's an error in thing1(), doTheThing() stops at that line and returns the rejected promise to whatever called it. The callback world is clearly the more complex here, where all error handling has to be properly wired and there is no default handling. The node callback equivalent to the above is: function doTheThing(callback) { thing1(function (error, value) { if (error) callback(error, null) thing2(function (error2, value2) { if (error2) callback(error2, null) callback(null, true) }) }) } You can't forget either if (error) check or else errors will just silently be eaten/ignored. The "implicit behavior" introduced by async/await are essentially the same things you are used to in code without async/away, such as the way try { } catch { } and throw naturally work in synchronous. That alone should be considered a simplifying improvement.
• dclowd9901 10y ago
  I think my problem with this approach is the way it throws away the functional programming paradigm JS has been sharpening over these last few years. When I see await, I'm reminded of Java or .net, languages that didn't traditionally have functions as first class citizens. OTOH, I can't complain about removing dependencies like "when" or "bluebird", and it'll be nice to not have to simulate promise returns in testing.
  • dvlsg 10y ago
    I think it's nice to have both options. I prefer the functional style of chaining promises for the most part, but there are definitely a few times when await is easier to use IMO (awaiting inside of a loop, for example).
  • Bognar 10y ago
    I don't see how it throws away the functional programming paradigm. This is basically Haskell's do-notation applied to JS Promises.
• treenyc 10y ago
  What about this nodejs async, https://github.com/caolan/async https://github.com/caolan/async May be a replacement until the async is implemented in V8
  • nailer 10y ago
    That's the most common node flow control library, and it's awesome, but it's still built on callbacks. With ES2016 you can have an async function return a value you can assign to with =. Or, short ver: less indentation.
  • onestone 10y ago
    It's not a replacement at all, and has almost nothing in common with what is discussed here (except the name).
• ch49 10y ago
  Why is "async" keyword needed? Can't JS engine infer from the use of "await" in a function that this function need to be async? I'm using async/await for a while now, and so many times I've introduced bugs in my code because i forget to put "async" in front of the function, or put "async" in front of wrong function. It's simply annoying to go back and put "async" when in middle of writing a function I realise I need to use await.
  • mstade 10y ago
    I'd agree with you, and I'm keen to learn the real answer. My guess would be that some initial optimizations can occur without having to also parse and analyze the body of a function, potentially having significant performance benefits to reducing the boot time of a program.
    • Klathmon 10y ago
      the simple version is that because `await` wasn't a keyword before, it can be a named function. So `await (x)` is ambiguous. Making the outer function `async function () {...}` makes await a keyword inside that function, allowing them to move forward with that syntax in a non-breaking way as the parser now knows that there can't be a function named `await` inside any async functions.
  • eloisant 10y ago
    That's how it works in C#, and personally I much prefer to have a clear declaration than having to rely on the interpreter parse the function to infer it's async.
  • matt42 10y ago
    I guess this is because you do not always want to wait for a future just after the function call. In some cases, there is code you want to execute between the call to an async function and the use of its return value. A simple example would be the concurrent fetch of two urls.
  • ilkkao 10y ago
    Reason is mentioned here: https://github.com/tc39/ecmascript-asyncawait/issues/88#issuecomment-181517500 https://github.com/tc39/ecmascript-asyncawait/issues/88#issu...
• serguzest 10y ago
  It has been in Microsoft Edge/Chakra for a while. But I couldn't make it work with Babel + webpack2. I still needed babel for static properties and React. It was either webpack parsing couldn't recognize async/await or webpack executes modules on Nodejs which wasn't supporting asyn/await by the time. So bundling was failing. I wonder if there is any babel/webpack gurus out there can make it work ? Oh btw, I recommend windows users to try microsoft edge for debugging and runtime inspection, it is so slick :)
• chukye 10y ago
  Man, I used to love the times when try/catch was used to exception only, and with exceptions that leaves the program in a bad state, I used to think when you see a throw something really bad is going on, not just a simple ajax fail. Dont know why people love so much async/await. In the end of the day, this all (in node land, for instance) will be just a function call in the libuv, this will never change, this is because the pattern is really good.. Why overcomplicate that?
• ConAntonakos 10y ago
  So what does this mean in terms of being implemented in Node.js? How soon can we expect that to happen?
• derrickroccka 10y ago
  This is so good. Great days for JS. This is going to save us from a lot of headaches.
• z3t4 10y ago
  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); }); }