On: jQuery v4.0 Beta

[dylan604]

you think it's the same, but it's not even close to me

  .ajax({
    success:function(result),
    error:function(xhr),
  }

vs

fetch().then((e)=>function()) is even close to being the same, then we're just not even talking the same language

[erhaetherth → dylan604]

function ajax({url,success,error}) { fetch(url).then(success, error) }

Boom, same syntax if that's what you prefer.

J/K, the error status handling is not the same and the auto-deserialization isn't present. Not hard to add but it's harder to argue not to use a lib instead of copy-pasting 114 lines of niceties into each project.

[duskwuff → erhaetherth]

> the auto-deserialization isn't present

You mean like response.json()?

[umvi → dylan604]

You would just do:

const response = await fetch(...)

Bam, now you have the response without needing callbacks.

[dvt → umvi]

The async/await design is absolute garbage and no one will ever convince me otherwise. `fetch` is a particularly egregious example: it has all kinds of insane random quirks that you need to memorize. For example, how do I handle an error there? What's the obvious way to handle it? Is response null or something? Well, not exactly, you need to check for:

    response.ok;     // false
    response.status; // 404

Um, okay, I get it. So to get the text content of the response, I just need to do response.text, right? No, you dummy, that's a function! You need to call response.text(), duh. It's so funny how an entire generation of front-end engineers just accepted this slop as acceptable API design. You can't fix the past, but thank God for (oh the irony) Microsoft and TypeScript.

[hoten → dvt]

I don't see how the design of the fetch API relates to async/await being badly designed, can you explain?

[dvt → hoten]

For example, `response` can't ever be null (even though it would be totally expected to if the request borks) due to the fact that under the hood, you're dealing with a promise (probably the most boneheaded implementation of asynchronous programming). async/await tries to put lipstick (syntactic sugar) on a pig (promises), and the fetch API, among many others, suffers for it.

[hoten → dvt]

I still don't know what specifically you'd want different. What would a better language construct be for an asynchronous operation that enabled a better Fetch API in your eyes?

Fetch returning null on a network error just seems the worst possible design, as you don't get any information about why it failed. Raising an error or rejecting the promise seems an appropriate choice for fetch. It failed to reach any server, so it cannot produce a Response object -- but it can raise an error with failure details.

[n_plus_1_acc → dvt]

There are many popular wrappers like axios that fix some of these things.

[mschuster91 → n_plus_1_acc]

The fact that these kinds of wrappers exist instead of the most popular wrappers eventually ending up standardized in JS directly is mind-boggling.

[Taurenking → n_plus_1_acc]

We'll just stick with all-in-one jQuery, thanks

[timeon → dylan604]

I'm genuinely curious. How does this difference affects you?