yeah that works, your statement is fine

nice, thanks!

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());

I think the await code is more explicit, whereas a callback is somewhat ambiguous

I'll be glad to do away with callbacks completely tbh.

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?

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

This is totally not what I'm asking, thanks.

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 .json() inside, but I don't see why you would ever want to do it if you can have the same result without the await boilerplate...

EDIT: got it, you want to do it inside an aync function with some other code after the await, then I think it makes sense in that case.

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;

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.

> it doesn't hand hold or make assumptions

Using MIME types isn't hand holding or making an assumption.

Yes, people who need the low level features will wrap it with a series of competing high level libraries. It's a missed opportunity to make a standard, capable high level API though.

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

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.

Present tense: https://domenic.github.io/streams-demo/

yes code like that works.