DEV Community

Fetch() is All you Need

Ruheni Alex on October 27, 2020

Now I know what you are thinking... puppies are cute right? No, Okay. It's a little overkill to always reach out for a third-party library to ha...

Read full post

ecyrbe • Oct 27 '20

I have to desagree on some points because axios is a much more powerfull request layer.

First, there are no fetch interceptors, you'll have to use another library for that.
Second, fetch does not exist on node, you'll have to use node-fetch emulating library.
Third, node-fetch has no proxy handling on node
Fourth, fetch error handling is a pain, you'll have to do extra work to extract it and handle edge cases.
Fifth, timeout handling and cancellation handling is so much more verbose with fetch.

All these points explain why so many of us prefer using a higher layer library like axios.

Ruheni Alex • Oct 28 '20

Hi! I totally agree with you.

I've noticed the tone I used was a little condescending. Sorry about that. I've made an update clarifying the intention of writing the article and some of the shortcomings of fetch. 🙂

Didn't mean to rattle you😅

ecyrbe • Oct 28 '20

Hello Alex,
No worries. I was not bothered at all by the tone of your post.
You have written a good article, with a lot of insights for developpers.
Keep it up.

Ian • Oct 27 '20

Yeh agreed. Fetch isn't a replacement at all for axios, axios simply provides so much more than just fetching something. +1 for interceptors I was going to mention but you beat me too it :)

Margaret W.N • Oct 27 '20

Cave painting😂😂. Woow!

Etienne Burdet • Oct 27 '20

Yep, there is a reason why SSR frameworks still favor Nuxt. It's hell with fetch, there's is always calls responding weirdly.

Ruheni Alex • Oct 27 '20

How does isormophic-unfetch perform in SSR using Nuxt?

Etienne Burdet • Oct 27 '20

That's a good question! Never tried it, but seems very attractive. Very minimalist.
Zapper has a nice approach: replacing fetch or this.fetch as needed (being a compiler it's easy enough to do). Effectively, you're just writing you're only using fetch.

Devin Rhode • Feb 26 '22

cross-fetch would be worth considering these days github.com/lquixada/cross-fetch

Thomas Ferro • Oct 27 '20

Nice article but beware of the response.json() call before checking reponse.ok, it may get you or anyone copying your example in trouble!

I found this video by Joel Thoms to explain clearly the issue: youtube.com/watch?v=aIboXjxo-w8

Ruheni Alex • Oct 27 '20

Learnt something new today! Thank you for sharing

Ronald Rey • Oct 30 '20

There's one specific case I'd like to point out where XMLHttpRequest could be preferred, and is regarding cancellations.

When you abort a fetch call, you are aborting the network call, but the Promise itself is not canceled because Promises don't support cancelation. As you can see, the actual behavior is that the promise throws.

This is fine for most cases and practically all product development, but in very specific and extreme circumstances this might not be desired because Promise ticks are actually expensive and can clog the stack, which can end up having a consequence in the execution flow of the program.

A callback-oriented API that doesn't rely on Promises doesn't have this drawback, and that just wouldn't be possible to do with fetch, but is possible to do with XMLHttpRequest.