AFAIK, there was a time when the "module ecosystems" were essentially split between requirejs (AMD) on the front and CJS in the back.
Fetch is also not XHR, and has different security defaults and trade-offs.
I should say 'HTTP request' rather than XHR but the point still stands: having different objectives doesn't make it OK to ignore mime types, have people manually encode JSON, have people manually encode query strings, and all the other things we already have now in fetch. Which nobody will use (unless they want to cancel requests) because we already have better solutions with less needless boilerplate.
I also don't know what you are talking what we already have in fetch. It you are arguing WHATWG should have just adopted superagent, I disagree. The major difference between fetch and XHR is the ability to stream content. Fetch only needs to be better than XHR. Superagent uses XHR internally, and it's extremely difficult to have XHR support streaming without turning its API to an even bigger mess. Encoding JSON yourself is a one-liner in JS. Encoding query string is also easy, there's a whole new URL object to help you now. If not, it's just a tiny function away. It's not hard to wrap fetch at all.
Yep, which explains the ignorance. None of the other modules systems are a hundred thousandth the size of npm, so don't matter.
> I also don't know what you are talking what we already have in fetch.
Literally POST some JSON to a resource with a query and compare the code using superagent to the fetch API.
> Encoding JSON yourself is a one-liner in JS. Encoding query string is also easy.
That is irrelevant. Defaults should be sane.
They just didn't adopt it wholesale.