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

131–140 of 227 posts

Re: JavaScript async/await implemented in V8

#131

Post by eloisant »

ch49 wrote: post #128

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…

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.

Re: JavaScript async/await implemented in V8

#132

Post by nailer »

startling wrote: post #7
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 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?

Tip: if you use anything other than fetch you'll just get JSON back immediately based on the MIME type, without the unnecessary conversion step.

Re: JavaScript async/await implemented in V8

#133

Post by nailer »

treenyc wrote: post #120

What about this nodejs async, https://github.com/caolan/async May be a replacement until the async is implemented in V8

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.

Re: JavaScript async/await implemented in V8

#134

Post by matt42 »

ch49 wrote: post #128

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…

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.

Re: JavaScript async/await implemented in V8

#135

Post by tomp »

turblety wrote: post #129
tomp wrote: post #127

Earlier 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…

It might be something to do with backwards compatibility.

What do you mean? Edit: I mean, can you give any examples of how old code would be broken by implementing something like this?

Re: JavaScript async/await implemented in V8

#136

Post by ilkkao »

ch49 wrote: post #128

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…

Reason is mentioned here: https://github.com/tc39/ecmascript-asyncawait/issues/88#issu...

Re: JavaScript async/await implemented in V8

#137

Post by Kiro »

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.

Why do you need to put await before res.json?

Re: JavaScript async/await implemented in V8

#138

Post by tomelders »

Kiro wrote: post #137
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.

Why do you need to put await before res.json?

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.

Re: JavaScript async/await implemented in V8

#139

Post by amelius »

tomp wrote: post #127
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.

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…

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.

Re: JavaScript async/await implemented in V8

#140

Post by rpastuszak »

spraak wrote: post #124
bb85 wrote: post #23

Earlier quoted context omitted.

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.

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.

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

Post reply on HN