A new standard would need buy-in from browsers to actually be a standard. Browsers likely don't have a lot of incentive to make spec changes only Node is interested in (like making the whole spec more complicated from their point of view because of Node's (or Deno's) different security model).

The level of collaboration and good-faith we've been getting from spec bodies like WHATWG is very high as it is and we really don't want to push or abuse it.

Does it have to be a buy-in, though? You could agree on server-specific extensions to fetch and codify them in the same spec (so it doesn't get lost otherwise). Browser vendors wouldn't need to implement it but they will still keep an eye on it when working on future browser apis.

Codifying the redirect behaviour for server/"trusted" envs makes some sense with Deno/node doing the same thing. I'm not versed enough in the standards orginazation politics to say if that's viable though.

The rest of your "improvements" aren't that. They're opinions, opinions laser focused on a JSON centric api.

I'm sorry to say this, but not all of the web is one big JSON blob.

Some of us have to talk to SOAP (xml) services.

Sometimes it's weird rpc stuff with protobuf.

Or even just pulling down raw binary data and feeding that through an API/library that wasn't built for web streams.

Honestly, the amount of code you need to add over the top of a primitive like the Fetch API to get what you wanted (bar the redirect change) is trivial and minimal.

Can you share your setup for talking to SOAP services?

It would be useful for trusted browser extensions too, as well as probably Electon apps as well.

I don’t know if chrome apps are still in existence, but if they are the “server side” fetch spec could apply to them too.

> Browsers likely don't have a lot of incentive to make spec changes only Node is interested in

All the existing HTTP clients discussed in the previous post also run in the browser.

None of the things you mentioned are reasonable default behaviours, and are easy one liners. You don't need a library for any of that.

Thanks for your opinion, however as mentioned, or as you’ll be aware if you’ve used JavaScript, these are well worn cow paths that have been default in the most popular HTTP clients for a decade now.

Why is this being down voted? This comment seems to be making a reasonable case.

In case you disagree, you may want to reply why instead of down voting.

Because fetch just landed in Node.js, making it a standard present in every context after like 5 years and he want to change the standard now.

Edit: also, you are being downvoted because the etiquette on HN are that you don't ask "why was X downvoted".

As mentioned existing HTTP clients had this behaviour back in 2012, the designers of fetch chose to ignore these cowpaths in favour of a more minimal implementation requiring the use of third party HTTP clients in both browsers and node, simply to have reasonable defaults and not repeat oneself, for the foreseeable future.

the value the js community gets from `fetch` being a unified standard is far, far greater than the benefit you as a developer would get from not having to add 15 extra LOC around `fetch`, that you'll probably hide behind a `fetchJSON` function anyway.

Point is everyone had a slightly different 150 LOC or a library to achieve essentially the same thing.

We could have stuck with ‘if index is not equal to minus one’ but we have array includes now for the same reason.

I didn't downvote, but my guess is its primarily a kneejerk reaction to the following line:

> set JSON as the default request content type

or something similarly subjective.

Downvoting is going a bit too far, but bundling a few individual opinions on defaults alongside broadly accepted (implemented in both Node & Deno after much discussion) features seems... presumptuous.