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

161–170 of 227 posts

Re: JavaScript async/await implemented in V8

#161

Post by spb »

grandalf wrote: post #81
jeswin wrote: post #51

Earlier quoted context omitted.

Because you don't always have to await a function, and it isn't always possible for the runtime or language to decide whether to "await" or not. /* The following code may or may not use an await. Not await-ing would be better user experience. */ async function sendEmails(id) { ... } async function signUp(userData) { const user = await db.saveUser(userData); sendEmails(user.id); //

is the non-awaiting one guaranteed to finish (assuming no errors)?

It's guaranteed to return as soon as the thread of execution finishes prior immediately-pending callbacks (since it's basically a synchronous function call with an awaited return value). It's "finished" as soon as it's finished initiating the send, since it doesn't await the result.

(The exact point where this gets resolved, relative to other pending callbacks/resolutions, is a very wonky detail involving constructs not exposed at the language level, which varies from engine to engine in spite of what the standard says: https://jakearchibald.com/2015/tasks-microtasks-queues-and-s...)

Whenever the call resolves, even if the send does encounter errors, this function or its caller aren't going to know about it either way. That's why this kind of promise-abandonment is pretty bad design - I wouldn't be surprised if there's already a draft in the works for some kind of "use strict" option that causes warnings / crashes when synchronous code finishes with Promises unreferenced (or at least something in tooling / profiling to trace 'promise leaks').

Re: JavaScript async/await implemented in V8

#162

Post by [deleted] »

grandalf wrote: post #81
jeswin wrote: post #51

Earlier quoted context omitted.

Because you don't always have to await a function, and it isn't always possible for the runtime or language to decide whether to "await" or not. /* The following code may or may not use an await. Not await-ing would be better user experience. */ async function sendEmails(id) { ... } async function signUp(userData) { const user = await db.saveUser(userData); sendEmails(user.id); //

is the non-awaiting one guaranteed to finish (assuming no errors)?

[deleted]

Re: JavaScript async/await implemented in V8

#163

Post by moron4hire »

tehbeard wrote: post #143
nailer wrote: post #132

Earlier quoted context omitted.

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.

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

Re: JavaScript async/await implemented in V8

#164

Post by masklinn »

amelius wrote: post #157
masklinn wrote: post #155

Earlier quoted context omitted.

> Is it possible to have a yield inside a called function (i.e., not the generator function itself)? Call a generator function from a generator function? Sure, you just need to transitively yield its content using `yield* [[expr]]` (which delegates part of the iteration to the `expr` generator)

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.

Re: JavaScript async/await implemented in V8

#165

Post by neoeldex »

a-saleh wrote: post #147
amelius wrote: post #139

Earlier quoted context omitted.

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.

Is this the problem Python has solved with 'yield from' construct?

Its basically the same thing. But javascript doesn't come with a new eventloop and other construct to use it, since similar functionality is already in js

Re: JavaScript async/await implemented in V8

#166

Post by neoeldex »

moron4hire wrote: post #163
tehbeard wrote: post #143

Earlier 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

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

Re: JavaScript async/await implemented in V8

#167

Post by [deleted] »

tigershark wrote: post #123
startling wrote: post #7

Earlier quoted context omitted.

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?

I don't understand your code. the .json() should be inside the parentheses because you cannot await something that has already been converted from a Promise to a real value. And even in that case that code will be exactly equivalent to the synchronous code because you are awaiting in place the result of the Promise. So, given my very limited knowledge of javascript, I think that probably you can write it moving the .…

[deleted]

Re: JavaScript async/await implemented in V8

#168

Post by neoeldex »

tigershark wrote: post #123
startling wrote: post #7

Earlier quoted context omitted.

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?

I don't understand your code. the .json() should be inside the parentheses because you cannot await something that has already been converted from a Promise to a real value. And even in that case that code will be exactly equivalent to the synchronous code because you are awaiting in place the result of the Promise. So, given my very limited knowledge of javascript, I think that probably you can write it moving the .…

fetch() returns a promise, which is unwrapped using await. fetch's promise contains a response object, which has a json method, which returns a promise.

  const responsePromise = fetch(https://api.github.com/orgs/facebook');
  const response = await responsePromise;
  const jsonPromise = response.json();
  const json = await jsonPromise;

Re: JavaScript async/await implemented in V8

#169

Post by jwmerrill »

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?

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

Re: JavaScript async/await implemented in V8

#170

Post by danielstocks »

ascagnel_ wrote: post #152
dfischer wrote: post #53

Earlier quoted context omitted.

What do you use for the new fetch api on node?

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

fyi isomorphic-fetch is just a universal wrapper around node-fetch and github-fetch
Post reply on HN