Any advice on using fetch vs. axios vs. mithril's xhr?

[EverettMcKay]

I have been using fetch but am thinking of refactoring to use axios. But given that I'm using mithril, I'm wondering if xhr is the better choice.

Does anyone have any experienced-based advice here? Honestly, my top goal is to avoid surprises/future problems, as I already have enough of those.

[panoply]

It depends. For 95% of usage cases, XHR suffices and (imo) is a better choice. I base this on the following (incoming opinions):

JSON Parsing
This is huge for me. In XHR, there is no need to process JSON because we have response type as json, whereas in fetch you need to manually parse the response (await response.json()). This always bothered me and continues to bother me.

Progress Events
This is native in XHR, whereas in fetch (IIRC) you need to use a readable stream.

Native Timeout
XHR has timeout control available natively for request cancellation, while in fetch you'll need to use Abort Controller.

Error Handling
XHR differentiates between different types of errors, which makes things easier to reason with, whereas in fetch, network issues (excluding HTTP status codes) throw a promise rejection and require more explicit error handling. It's just a headache imo.

I would throw in the credentials argument here, but that would be petty given that fetch had issues with this early on, and despite that being resolved, it's still abstract imo. I suppose for me, I never really liked using the Fetch API, and having used the Mithril request API for years now, I've never needed or wanted more, especially for the context in which it exists.

Though XHR is no longer actively developed or improved, it is, just as Mithril is, rock-solid. Fetch does have "modern features," but it's important to note these "features" are typically just less verbose sugars around current implementations. Of course, it's important to consider if you'll need such features in your app, and I'd be willing to bet that very few would.

Take, for example, the "streaming" capabilities of fetch. The fetch API can take a ReadableStream interface to provide streaming of both text and binary data so one can start processing data as it arrives. This is considered a modern feature, but it can also be done with XHR using state change events to process in chunks from the response. If (however) we are talking about binary streaming (i.e., large binary files like video), the fetch API does things differently, and though XHR provides arraybuffer or blob response types, it does not allow you to process chunk-by-chunk but instead waits until the full response is available.

I don't mean to ramble on here, but I recently did explore the pro/con ratio of fetch and XHR, so it's fresh in my mind as it was discussed in a different project just a few days back. What I came out with was that there was no pressing reason for adoption of fetch at this point in time, when I considered what I need and use request handling for. If anything, if your ultimate goal is to mitigate future headaches, given that the maintainers and the community of Mithril place heavy focus on shipping breaking changes, by choosing the request API Mithril offers, you'll likely rest easier opting for it.

[dead-claudia]

Couple notes regarding progress notification:

• Streaming upload in fetch is relatively new and currently unsupported in Firefox at least.
• XHR progress events only track download, so in reality, you could just wrap the response body.
• fetch doesn't support correctly-reported upload progress at all. XHR does via xhr.upload.onprogress, but this isn't currently exposed by Mithril.

[EverettMcKay]

Nikolas and Claudia, thank you for your thoughtful answers. I will give XHR a go, as that sounds like the right choice.