Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript async/await implemented in V8

chromium.googlesource.com

Post reply on HN
Print view View original

31–40 of 227 posts

Re: JavaScript async/await implemented in V8

#31

Post by spriggan3 »

avodonosov wrote: post #30

what's the point of explicitly declaring functions "async", and then explicitly saying "await". IMHO all this could be done automatically by language.

> 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-y...

Re: JavaScript async/await implemented in V8

#32

Post by wwwtyro »

avodonosov wrote: post #30

what's the point of explicitly declaring functions "async", and then explicitly saying "await". IMHO all this could be done automatically by language.

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.

Re: JavaScript async/await implemented in V8

#34

Post by coldtea »

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…

>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.

Being simple doesn't make them optimal.

Promises are a clutch for lack of a built-in language feature, and async/await is that.

They add extra visual clutter, they can eat exceptions [1], they break the intuitive flow of code, etc.

[1] Yes, only if they are used badly. That's kind of the point. C is an excellent language too if everybody never uses it badly. The thing is people do, and a feature/language that doesn't need a corner case or mental model to keep in mind is better than one that does in that regard.

Re: JavaScript async/await implemented in V8

#36

Post by Bahamut »

norman784 wrote: post #22
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…

The think about using async/await its to write less code, make it much simple and makes also easy to try/catch errors. The think I don't like about promises its that you need to write a lot of lines that you could avoid with async/await, i.e: new Promise(function(success, failure){ db.fetch('sql...', function(err, data){ if (err) failure(err) else success(data) }) }) VS var data = await db.fetch('sql...') Also if you…

To correct this a little, the proper way to catch with promises is .catch, not with a try-catch inside a .then - that is an antipattern. The promise examples as written are not proper promise usage.

I'm also in the boat of confused people of why is async-await requested by a good portion of the js community - wrapping the block within the function in a try-catch seems like a bad idea, a brute force mechanism. IMO this is language bloat, and does not really solve problems we have while introducing a more expensive vector for managing flow (try-catches).

One missed point about the .catch with promises is that it allows you to branch flow discretely - it is not a perfect solution for branching flow (it is awkward when branching due to more than just a binary outcome), but with await, one might end up writing repetitive code for certain flows where one expects common calls to be made downstream in async data fetching flows.

Re: JavaScript async/await implemented in V8

#37

Post by hzoo »

foota wrote: post #12
tanto wrote: post #4

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.

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.

If you don't want to use regenerator and your environment supports generators already you can use the async-to-generator transform https://gist.github.com/rauchg/8199de60db48026a6670620a1c33b...

Re: JavaScript async/await implemented in V8

#38

Post by coldtea »

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…

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.

Re: JavaScript async/await implemented in V8

#39

Post by AgentME »

foota wrote: post #12
tanto wrote: post #4

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.

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.

Async/await is just syntax-sugar around Promises. No busy loops involved. (Those generally don't work in Javascript anyway.)
Post reply on HN