4 ms·
I think one thing to keep in mind is that just because something is available in the browser, that doesn't mean that all other approaches are suddenly moot and
by Vinnl 3y ago
I think one thing to keep in mind is that just because something is available in the browser, that doesn't mean that all other approaches are suddenly moot and will never be able to displace it - XMLHTTPRequest is also still available, for example, but did get replaced by `fetch`.
But in general, you raise a good point - just because something worked well with developer tooling, doesn't mean that it would work well when integrated in the browser. You see the same e.g. when people are calling for runtime type validation in the browser just because they like TypeScript, even though the pros and cons would be completely different.
- vanderZwan 3y ago> XMLHTTPRequest is also still available, for example, but did get replaced by `fetch`. True, although that also highlights my "once it's standardized the vendors are stuck with it forever" point
- 8n4vidtmkvmk 3y agoAnd XHR is still better than fetch. It supports progress events and SSE. I'm not really sure why fetch exists if it doesn't add new/better functionality. It's handling or lack of handling 302s is crap too. You can set it to "manual" handling but then can't manually handle it.
- earthboundkid 3y agoFetch exists because everyone just writes a 10 line adaptor function that looks like fetch anyway, so might as well build it into the browser and save the trouble for people who don't need progress events.
- 8n4vidtmkvmk 3y agoEh... the API is a little nicer but if it's weaker overall I think we might as well keep using the XHR wrappers over bloating the standard API. I end up wrapping fetch with with more niceities anyway.