4 ms·

I'm very interested in what "largest module ecosystem" you were referring to and what you mean by "the amount of lines it takes to do an XHR in the 'fetch' API

I'm very interested in what "largest module ecosystem" you were referring to and what you mean by "the amount of lines it takes to do an XHR in the 'fetch' API vs superagent in, say, 2012." 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.

nailer 9y ago
CommonJS (via npm) is used on more front-end code than TC39 modules are to this day. 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.
- wyuenho 9y ago
  TC39 had been talking about JS modules for about decade, before CJS even existed. CJS is unsuitable on the frond end because it's synchronous and does not enable static analysis. CJS being more popular on the front end is a very recent phenomenon, it really started to take off when React took off. AngularJS had its own module system and everything jQuery were essentially AMD first. 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.
  - nailer 9y ago
    > TC39 had been talking about JS modules for about decade, before CJS even existed. 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.

nailer 9y ago

CommonJS (via npm) is used on more front-end code than TC39 modules are to this day. 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.

wyuenho 9y ago
TC39 had been talking about JS modules for about decade, before CJS even existed. CJS is unsuitable on the frond end because it's synchronous and does not enable static analysis. CJS being more popular on the front end is a very recent phenomenon, it really started to take off when React took off. AngularJS had its own module system and everything jQuery were essentially AMD first. 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.
- nailer 9y ago
  > TC39 had been talking about JS modules for about decade, before CJS even existed. 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.