Introduction
Earlier this year when i worked as an Instructor in a bootcamp teaching Full-Stack Software Engineering, a student asked wh...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks so much for the feedback.
I did not forget to add isomorphic-unfetch.
I just didn't know about it yet. Lol...
About the open issues, react and flutter has 600+ and 5000+ open issues respectively.
Measuring the awesomeness of a library or framework by using only open issues and PRs alone is not a good yardstick. You need to include other variables to your analysis to draw a conclusion that is more precise and reflects the opinion of the community using the said library or framework.
Thanks for the feedback once again and i have mentioned isomorphic-unfetch in the article. But you'll be the one replying to any question related to that library in the comment section ;)
There is also the request package (npmjs.com/package/request), although for Node only. It has 15M downloads weekly while Axios has 5M only.
I'm in trouble. The list never ends :(
Oddly enough I always bring up
axios
when I want to talk about how not to write an HTTP client. I think a lot of the decisions around the design of its API make it harder to use in the long run. Two examples:Conflating network errors with valid HTTP responses. While it's initially easier to use, I've found it inevitably leads to confusion about what the source of an 'error' is. I much prefer the explicit handling of different HTTP responses (including 4xx and 5xx) that the
fetch
api encourages.What happens when the auto-parsing of JSON fails: nothing. Axios will swallow the error and leave you trying to access properties on a string that don't exist. Extremely hard to debug. The owner recognises the problem but has no solution
With axios we gain some convenience but at the expense of control and transparency. What we have to ask is whether it is worth the trade. Is the removal of a single method call to parse JSON worth the time it will take to work out what's going wrong when it (inevitably) does go wrong? Is the convenience of throwing on a 404 worth the pain of reconfiguring the client so that it doesn't throw on a 404 when I'm expecting a 404 response?
I prefer simple but verbose in the style of fetch; everyone has to make their own mind up.
Thanks for the feedback.
You have made a clear case with some strong points.
I learnt from your comment and i appreciate it.
Every library has its downsides and tradeoffs. You just have to choose what you can manage and which gets the job done.
Axios shines in terms of convenience and has a simpler API. This might be what a developer wants at some point. The issue link you shared definitely has some workarounds. No library is perfect. I absolutely get your point and you passed your message in a very clear and consise way. I respect that.
This article was just a way to show beginners why thousands of articles and tutorials use third party libraries like axios for node.js based projects. Most articles don't tell them why.
Ahh...lastly, i would update the article with my conclusion. Wrote this article at midnight so i missed that.
Thanks once again David
Enjoyed the article, thank you for sharing 👍In addition to this list, I find the biggest advantage of axios is that it is using XHR internally, meaning we can get updates on request progress 🎚️(onUploadProgress and onDownloadProgress).
Didn't know that until now. Thanks for sharing..
The other thing that I've found that
axios
can do that I couldn't getfetch
to do correctly was to properly save a cookie to use for post requests over https (I think that was the issue) in a React Native application. It's been awhile, so I don't 100% remember the specifics - but I remember thataxios
worked whenfetch
didn't.Thanks for the post!
Ah nice.
You're welcome
Totally agree! Axios loooks like is not maintained.
Interesting discussion about 1.0
github.com/axios/axios/issues/1333...
Issue about esm version since 2018
github.com/axios/axios/issues/1879
Initial maintainers:
github.com/axios/axios/issues/1965...
Nowadays maintainer:
github.com/axios/axios/issues/2531...
Thanks for the feedbacks.
Would update the article by Monday with examples to show more differences between the two.
More ideas are coming in :)
I often use isomorphic-unfetch myself, it's a good choice
Error handling is very nicely done in axios too. With fetch lots of if statements for simple error handling.
Ah this is true. I intended adding that to the article but forgot.
Yeah. fetch throws for only network errors and you'll have to manually check for other errors unlike axios.
Guess I'll have to add this to the article with an example.
Thanks for sharing
Very nice and informative article.
Thanks a lot.
I use the isomorphic-unfetch too, i think axios is like a "nice to have" but it isn't the most useful library.
unfetch used only by 50k
"superagent" lib used by 250k and it much more maintained
Great article! I came across axios a while back, but enjoyed the read and clarifying points. Appreciate the write up!
I'm glad you liked it.
One nice thing about axios is the pre/post request hooks. You could use them for say add authentication tokens and globally handle request errors.
Ah!! A win for axios :)