What about this nodejs async, https://github.com/caolan/async May be a replacement until the async is implemented in V8
It's not a replacement at all, and has almost nothing in common with what is discussed here (except the name).
JavaScript async/await implemented in V8
171–180 of 227 posts
Re: JavaScript async/await implemented in V8
#172It 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 :)
Re: JavaScript async/await implemented in V8
#173Earlier quoted context omitted.
const is more declarative as you can immediately tell that the data isn't going to change throughout the duration of the program (although technically you can change the data, just not the reference).
> although technically you can change the data, just not the reference This is why I'm hoping to see native JS immutable data structures eventually (maybe it's already in a proposal somewhere?). ImmutableJS and Mori are great, but having a native solution that's available everywhere would be ideal.
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.)
Re: JavaScript async/await implemented in V8
#174Earlier quoted context omitted.
Those other than fetch()s still do the "unnecessary conversion step". Don't dismiss fetch by the fact it doesn't hand hold or make assumptions. It should be said that fetch() is quite low level call compared to what we've had before regarding ajax, so it makes sense in larger projects to wrap it to keep any logging, error handling and retry in one place.
Fetch API also doesn't have any means of tracking progress, making it strictly inferior to XmlHTTPRequest
In fetch's defence it will in future once the Streams API is finalised: https://github.com/whatwg/fetch/issues/21
Re: JavaScript async/await implemented in V8
#175The 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.
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…
The explicitness is the reason currently you can assume* that if nobody will ever modify variables unless you explicitly give up control somehow, if you were to have implicit await then that would no longer be the case and any function call could theoretically pause the function and give up control to other functions.
*certain DOM APIs due violate this contract, notably window.open() on firefox pauses everything but setTimeout.
Re: JavaScript async/await implemented in V8
#176Earlier quoted context omitted.
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…
The explicitness is the reason currently you can assume* that if nobody will ever modify variables unless you explicitly give up control somehow, if you were to have implicit await then that would no longer be the case and any function call could theoretically pause the function and give up control to other functions. *certain DOM APIs due violate this contract, notably window.open() on firefox pauses everything but…
The problem with that is that any mutable escaped variable (i.e. explicitly or implicitly global) can be potentially modified by any function call. On the other hand a non escaped variable cannot be mutated behind your back, yield or no yield. At least, that's the case in a sane language, not sure about JS.
Re: JavaScript async/await implemented in V8
#177Earlier quoted context omitted.
The explicitness is the reason currently you can assume* that if nobody will ever modify variables unless you explicitly give up control somehow, if you were to have implicit await then that would no longer be the case and any function call could theoretically pause the function and give up control to other functions. *certain DOM APIs due violate this contract, notably window.open() on firefox pauses everything but…
The problem with that is that any mutable escaped variable (i.e. explicitly or implicitly global) can be potentially modified by any function call. On the other hand a non escaped variable cannot be mutated behind your back, yield or no yield. At least, that's the case in a sane language, not sure about JS.
escaped/non-escaped variables are not a thing in JS
Re: JavaScript async/await implemented in V8
#178Earlier quoted context omitted.
The problem with that is that any mutable escaped variable (i.e. explicitly or implicitly global) can be potentially modified by any function call. On the other hand a non escaped variable cannot be mutated behind your back, yield or no yield. At least, that's the case in a sane language, not sure about JS.
escaped/non-escaped variables are not a thing in JS
There are no locals in JS (honest question)? If that the case you have to assume that everything can be mutated everywhere unless for those functions that explicitly and fully document their side effects (and yield would certainly be a side effect).
Re: JavaScript async/await implemented in V8
#179Earlier quoted context omitted.
So what tomp is doing: const res = fetch('https://api.github.com/orgs/facebook'); // yield here actually requires a "yield" in front of the "fetch"? But what if I want the fetch() function to decide whether to yield or not? Of course, fetch(), could yield a status specifying whether its calling-ancestors should yield, but this can become unwieldy very quickly, and might require an exception mechanism of its own. Bett…
In javascript it would yes (actually a `yield*`, or an `await` in async/await). With native coroutines it wouldn't (the runtime would implicitly yield on IO). > But what if I want the fetch() function to decide whether to yield or not? In javascript? The question doesn't really make sense, a function is either sync or async.
> The question doesn't really make sense, a function is either sync or async.
Well, either fetch() blocks, or not. If it blocks, then it should yield, its caller should yield, etc. If it doesn't block, then it can just run to completion.
Re: JavaScript async/await implemented in V8
#180Earlier quoted context omitted.
Fetch API also doesn't have any means of tracking progress, making it strictly inferior to XmlHTTPRequest
Fetch does have streaming uploads and downloads, and a quite some other features which doesn't come with xmlHttpRequest. Making it not strictly inferior to XMLHttpRequest
Will have. Future tense. Not present tense.