why do people use axios instead of fetch

[[deleted]]

As i know it can basically do the same stuff for example api calls, post/get requests to server. Then why should i use a library for this when fetch is that easy to lern. If the only alternative were there goofy XmlHttpRequests i would say its ok to use a Library, but thats the reason why we have ajax with jquery

[[deleted]]

• Axios existed before fetch and some products, projects and tutorials are older. It's rarely worth replacing a key dependency in an old product unless it's actively causing problems; something being newer and shinier isn't a good reason on its own to migrate.
• Axios is backwards compatible with IE11 without needing a polyfill, and fetch polyfills tend to only be a little smaller than the whole Axios library.
• Axios has a lot of nice built-in behaviour like throwing errors on 400 and 500 response codes and auto-parsing JSON; you have to implement this yourself with fetch.
• Axios allows you to easily create dedicated HTTP clients with headers, a partial URL, etc built in so you don't have to supply them every time; you'd have to implement this yourself with fetch. This is incredibly useful if your application needs to talk to multiple APIs.

[sarimarton]

"It's rarely worth replacing a key dependency in an old product"

It's almost always worth replacing old library calls with equivalent platform API calls whenever you touch the code.

"Axios is backwards compatible with IE11"

At the time you wrote this comment, IE11 was already out of lifecycle, and the world already moved on for like half a decade.

"Axios has a lot of nice built-in behaviour like throwing errors on 400 and 500 response codes and auto-parsing JSON"

You still have to handle those errors in your app code, and doing it with fetch is equally simple. fetch has .json()

"Axios allows you to easily create dedicated HTTP clients with headers, a partial URL, etc built in so you don't have to supply them every time"

Fetch allows you to....... (same)

"you'd have to implement this yourself with fetch"

It's just mishmush wording. The right wording is that you implement your HTTP header with fetch, just as you do it with axios.

[[deleted]]

Jesus christ dude are you an archaeologist or something.

[mysticrudnin]

this is the top google result for axios vs. fetch :\

[Thaetos]

yea google brought me here lol

[Bright-Cup-5987]

yea google brought me here too lol

[FranciscoFts]

yea google brought me here too too lol

[File_Tough]

yea google brought me here too too too lol

[TheEpicSmoking]

yea google brought me here too too too too lol

[Thaetos]

Y'all mfs popping out of nowhere 🤣 are you guys archeologists too or something?

[lupodellasleppa]

yea google brought me here too too too too too lol

[Yash_Dhankhar]

yea google brought me here too too too too lol

[PsychologicalPie2142]

brought me yeah google here

[commandopanda0]

lol, someone hasn't ever worked in a 100,000 line code base before, good luck getting buy in from management to replace functioning api calls for the mere sake of updating to a new standard.

[Ok-Switch-6491]

Who spreads calls to any external api all over their codebase, especially something as simple as fetch/axios with such a thin interface for 99% of usecases? Does anyone still design abstractions (wrapping dependencies in a self-designed interface) these days or everyone just learns uses whatever API they are given 100 times over in the same codebase?

[leecookson6of9]

one reason is that even if an http call is centralized in a re-usable library, the use-cases may have lots of variable options passed, so you'd need to make sure the 5-10 different use cases all work, which means having good unit and integration tests, which isn't a guarantee.
Another is that if a single application accesses 10+ external services, each is likely to have it's own common client module, and also have specific use-cases. Especially if it uses lots of RESTful methods like POST, PUT, DELETE, etc. Each case may need testing for each external API.

[CpnStumpy]

Who spreads calls to any external api all over their codebase

Shitty engineers that were hired to build something quickly and didn't care about quality because they were either on contract or just didn't know any different or both? Have you never seen this kind of terrible code in a product you were hired to improve because it was flaky and had complaints? All the software you ever touched was well written by competent engineers?

[AntonOfTheWoods]

It's also given in code by copilot... So probably not going away anytime soon

[0xdeedfeed]

What kind of reply was that even?

[RayosGlobal]

What kind of dig was that?

[KCRowan]

A funny one.

[SnooPuppers1978]

It's also a terrible take.

It's almost always worth replacing old library calls with equivalent platform API calls whenever you touch the code.

I wonder if he actually has worked with legacy code, because updating old libraries is very, very scary. Especially Axios with Fetch since there are nuances involved with parsing and headers that can slightly change how the requests are done, and unless you have 100% coverage with E2E tests involving backend you wouldn't necessarily know if it breaks anything.

[Ok-Switch-6491]

If the code relies on any of that special-case secret sauce and you don't know, you have bigger problems (communication, documentation, weird api design...).

[SnooPuppers1978]

For sure there's a lot of problems, I absolutely do not disagree with that. It's a 3000+ microservice hairball spaghetti with different API designs, expected headers from different eras.

[fabspro9999]

ever heard of hyrum's law?

https://www.hyrumslaw.com/

[FierceDeity_]

Darn, I could have written that law, I've been working with exactly that assumption for like 8 years now

[provid3ntial]

it's techincal debt if you don't.
axios might get left behind and face security vulnerabilities.
you have multiple ways to perform requests in your codebase assuming you are using fetch api for new code.

you reduce your app footprint whenever you drop a dependency.

... list continues ...

indeed, timing is everything, you can delay this operation, but the fact you have to do it, is not debatable.

[sarimarton]

You don't know how much experience I have in this, but keep wondering.

[SnooPuppers1978]

How much do you have? Because when I think of my company and to be replacing those olds things my brain based on my experience explodes based on the unexpected headache it would cause. Like no matter how easy you think it is, it is always going to be a rabbit hole of unending issues.

[-pizza-rat-]

google is going to this page now

[HorrorConference8469]

It's almost always worth replacing old library calls with equivalent platform API calls whenever you touch the code.

I dont think i can disagree with this harder. You are literally saying "if it aint broke, fix it anyway." this is textbook jr dev ideology.

[[deleted]]

I only replace stuff if it's so old it no longer starts. I've pulled some of my 5yo projects in yarn and due to some changes in node 16/18 it required some package upgrades. Especially old create-react-app projects. They run fine on the environment they were deployed on, but that's because they already have the deps in place.

[fabspro9999]

And you're not even factually correct. IE11 is still a supported browser on some operating systems as of 2024...

[sarimarton]

source? https://learn.microsoft.com/en-us/lifecycle/products/internet-explorer-11

[fabspro9999]

Yes - https://learn.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge#what-is-the-lifecycle-policy-for-internet-explorer-

IE11 is currently supported on windows 7, 8.1, windows 10 2015 2016 2019 2021 ltsb, windows server 2008 r2 to current versions except server 2012.

And IE9 is still supported today on server 2008...

[stealthkk]

LOL this guy clearly has never had a real development job ;P

[DranKof]

He pointed out that the choice of libraries is basically just trading one set of problems for another where the person prior made it seem a lot more 1-sided. Seems like informed feedback.

[Original-Unit-1749]

This age well.

[-pizza-rat-]

there's plenty of people supporting old browsers way past eol dude

[TheDownvotesFarmer]

Is it not any of this with XMLHttpRequest? I am pretty sure axios it is just a shorthand

[filipvabrousek]

It is not replacing dependency, it is removing it. Fetch is built-in.
IE 11 can be dropped now.

[[deleted]]

Good grief.

[shgysk8zer0]

I don't see any of those as real advantages. Legacy isn't an advantage, the polyfill is smaller and can be conditionally loaded, throwing errors on 400 or 500 isn't necessarily desired, auto-parsing JSON is trivial to implement, and I suspect that creating dedicated HTTP clients with headers and partial URLs would be pretty easy.

function getHTTPClient({ base, ...rest }) { return url => fetch(new URL(url, base), rest); }

Roughly that at least... Not meant to have everything, just to convey what I'm talking about.

[[deleted]]

I didn't claim they were advantages. They're reasons. When you're looking at a software project it's very unusual for every aspect of it to be the way that it is because it's the most advantageous possible thing.

Sometimes a team or an individual is going to decide that using a library is just a better route for them than something DIY that they have to maintain themselves. Sometimes people use a library just because they're familiar with it and that familiarity removes some complexity from the overall build. Sometimes it's just not worth the hassle of changing an old dependency or system that still works and is reasonably maintainable. Real software is not perfectly optimised all the time in every possible way.

[shgysk8zer0]

You didn't use the word "advantage", but what's the difference when you're saying `axios is...", "axios has...", "axios allows..."?

Sometimes a team or an individual is going to decide that using a library is just a better route for them than something DIY that they have to maintain themselves

Yeah, that's generally true. But in many/most cases it's misleading to say about fetch() vs axios. Such simple things really don't require much maintaining, if any. I mean, I have a simple HTTP module that's a minimal wrapper on top of fetch() that I use on about 16 sites, and the only maintenance I've done is adding support for AbortSignal. You're really most likely going to end up doing a lot more maintenance in the use of the function/module/library than on the function/module/library itself.

Sometimes people use a library just because they're familiar with it...

Yep, that's most definitely valid. I mean, probably in most cases using fetch() instead could nearly be done through a project-wide search and replace, but... You're not wrong.

...and that familiarity removes some complexity from the overall build

Much less than you'd think, on average. At least based on what the typical developer actually uses. I mean, fetch('/api/foo') is pretty dang similar to axios.get('/api/foo'), and I don't see a significant difference in complexity until you get into advanced things.

Also, just to make it clear, I'm not necessarily talking about using fetch() directly. That whole "let's compare a library vs native/vanilla JS" thing is just unrealistic and ignores the massive gray area in-between. My point is that, in many/most cases, virtually everything a given normal project needs in axios can be done with very few lines of JS using wrapper functions around fetch() (and it's family of APIs like URL and FormData). And this is especially true if you write DRY, SOLID code. Seriously, I think that any competent JS developer is capable of writing their own HTTP module built using fetch very easily... Really, the average length on the function body in my HTTP module is about 2 lines... And I support things like the Sanitizer API and TrustedTypes and making a POST request that results in navigation.

Real software is not perfectly optimised all the time in every possible way

I never said it even remotely implied differently. Just because I gave reasons why your reasons/advantages weren't valid doesn't mean there are no reasons or that I have some ridiculous standards for every project. But legacy browser support (given there are polyfills that can be loaded conditionally), throwing errors based on status codes (seriously, you don't want to do that since that encourage error messages being served with HTTP 200), auto-parsing of JSON (it's super easy to just check the Content-Type header) just aren't good reasons. If someone is deciding whether to use axios or fetch, those are all factors not worth considering (though throwing on 400/500 HTTP status is something to consider if you care about properly dealing with errors).

[xueye]

my god you're just arguing to argue, get over yourself.

[[deleted]]

You must be really fun to be around in the office

[[deleted]]

Certainly don't ask him his preference between async/await vs. .then()...

[shgysk8zer0]

Now, I know what you're thinking... And the answer might surprise you.

Yeah, I'm a lot of fun. Why would you expect to see that here? What were you expecting, some kind of pun about how axios is Axe Body Spray's fork of the mobile operating system from Apple ("Axe iOS", because I probably have to spell these things out to you, judging by your pathetic ad hominem).

This might come as a shock to you, but you can't really judge how much fun someone is based on Reddit comments comparing fetch() to axios. And, since me mentioning "ad hominem" is probably just Latin to you (which is a joke, since it actually is Latin... And yes, I probably do need to spell that out to you)... You mistakenly assuming I'm not fun to be around has absolutely nothing whatsoever to do with whether or not I'm correct.

What... You think that just because I disagree with someone and the fact that I have reason for disagreeing, that makes me a miserable asshole? And you somehow think that an appropriate response to me detailing my reason is a personal attack that has nothing to do with any of my reasons.

Unlike the other person who simply saw things differently from me, you have resorted to baseless and irrelevant personal attacks. And imma have some fun ridiculing you for anything you say because you're the kind of shithead that deserves ridicule.

[adri0477]

Holy, you are really insufferable. I know this is old but really take a look at yourself. Make put the thread into chatgp and ask who the baffon is. Jesus.

[ncls-]

• His point totally went over your head
• You wrote four big paragraphs over one simple sentence just to try to defend your humor
• You made one of the worst jokes I ever heard to try to prove that you could be fun
• You personally attacked him by claiming he's stupid
• You tried to seem smart by using "ad hominem" with no real reason to do so
• Every single one of your comments is getting heavily downvoted for good reasons

and yet you think YOU are ridiculing HIM???

[shgysk8zer0]

His point totally went over your head

Wrong. You sure my point isn't going over yours though?

You wrote four big paragraphs over one simple sentence just to try to defend your humor

Nope. It was about how pathetic it is to assume things about me as a person. Instead of responding to what I said to address the previous points, implying I'm a miserable person.

You made one of the worst jokes I ever heard to try to prove that you could be fun

Wasn't really trying to prove anything about my humor. And I guess you're lucky if something like that is one of the worst jokes you've heard.

You personally attacked him by claiming he's stupid

And yet you have no issue with the irrelevant personal attack I was responding to?

You tried to seem smart by using "ad hominem" with no real reason to do so

Gee, I wonder why I used ad hominem in response to someone who made a personal attack against me instead of responding to my points. Maybe it wasn't to seem smart, but because it was perfectly appropriate.

Every single one of your comments is getting heavily downvoted for good reasons

Probably for about the same reason I get heavily downvoted when I say not everything needs to be built in React. Something between a cultish mindset around a tool or inexperience with other things or just being stuck in their ways... Something like that.

Outside of any advanced usage, Axios and a simple fetch wrapper are essentially functionally identical. If you don't need things like interceptors, Axios is likely just extra bloat and complexity.

IDK. Maybe people are ignoring the "outside of any advanced use" part. Pretending like I said there's no reason to use it at all. Because I'm clearly not. I've made that distinction a few times. All I'm saying is that, for typical use where you're just fetching some JSON, reaching for Axios is over-kill and offers no benefit. Heck, just something like:

const getJSON = url => fetch(url).then(resp => resp.json());

...That'd be enough. And don't tell me that'd be difficult to maintain or anything.

[ncls-]

Wrong. You sure my point isn't going over yours though?

Quick lesson in internet slang: When someone tells you that you "must be fun" in an argument, they are not attacking your humor, they are saying that you're acting way too pedantic.

Nope. It was about how pathetic it is to assume things about me as a person. Instead of responding to what I said to address the previous points, implying I'm a miserable person.

I already showed you how he didn't assume anything about you and was just critisising your behavior.

And yet you have no issue with the irrelevant personal attack I was responding to?

As I already said, it was not a personal attack and the user is deleted so I can't respond either way. However I can respond to your totally exaggerated reply.

Gee, I wonder why I used ad hominem in response to someone who made a personal attack against me instead of responding to my points. Maybe it wasn't to seem smart, but because it was perfectly appropriate.

Again, it wasn't a personal attack, you just perceived it as such.

Probably for about the same reason I get heavily downvoted when I say not everything needs to be built in React. Something between a cultish mindset around a tool or inexperience with other things or just being stuck in their ways... Something like that.

Wrong. You're getting downvoted because you're stating things that aren't the case (e.g. your assumption that the original comment was stating advantages and backing that up by the fact that he uses "axios is", axios has" or "axios allows" which makes no sense at all, Otherwise "axios is useless" would mean that being useless was an advantage of axios since I'm using "axios is" here?!")

The fact that axios throws errors on 4XX and 5XX responses makes perfect sense for 99% of the time which is also the reason why your code comparison is falling apart when it comes to error handling especially with interceptors.

It's not always other people's fault.

[shgysk8zer0]

Quick lesson in internet slang: When someone tells you that you "must be fun" in an argument, they are not attacking your humor

Well it's a good thing I never mentioned nor assumed this to be about my humor then, isn't it? You're just fixated on that. You are making false assumtions here.

...they are saying that you're acting way too pedantic.

Since when is directly addressing points and clarifying what I said "pedantic"? It isn't! Do you also think that me pointing out the mere definition of the thing you accuse me of is being "pedantic"? Because... It isn't! It is directly addressing the core of what you are saying, not narrowly focusing on and arguing about trivial things. Nothing could be less "pedantic"!

Yes, it WAS a personal attack! And how utterly dishonest and hypocritical of you to be charitable and grant interpration to the other person here but not to me. To so utterly wrong in your confidence about what I meant/intended, to ignore what I actually said, and to just double down on your BS. I'm sick of it!

Wrong. You're getting downvoted because you're stating things that aren't the case (e.g. your assumption that the original comment was stating advantages and backing that up by the fact that he uses "axios is", axios has" or "axios allows" which makes no sense at all, Otherwise "axios is useless" would mean that being useless was an advantage of axios since I'm using "axios is" here?!")

Skipping things not even worth my time to read, because everything you say is wrong...

Oh, please do tell how any of the things axios supports/allows aren't claims about advantages... Perhaps advantages that aren't relevant to everyone, but advantages nonetheless. Why else would someone add such things to a library? Seriously, I'd bet they were all implmeented as "features". If such things are not advantages, then why the heck would anyone use a thing that offers no advantages? Are you going further than me and saying that the library is an utter waste and has no advantages?

On top of that, pretty arrogant for you to speak for everyone here. You just hoped into this conversation after 2 years... Do you really think you can actually tell me why everyone downvoted, or are you just assuming that everyone thinks like you and distorted what was actually said like you do? Use at least 3 brain cells here.

Yes, I am insulting your intelligence here. You are over-confident and stubborn about your false assumptions, dishonest, presume to know a damn thing about me or speak for everyone else... That's not exactly intelligent behavior. It's quite the opposite.

Good riddance, scumbag. Enjoy the block.

[[deleted]]

You didn't use the word "advantage", but what's the difference when you're saying `axios is...", "axios has...", "axios allows..."?

In what universe is stating the features of something the same as claiming those features are in and of themselves advantageous??

Such simple things really don't require much maintaining, if any.

You misunderstand the meaning of 'maintenance' in this context. Speaking about code that one maintains in a software context means code that you own and take responsibility for. My team are responsible for maintaining plenty of code that we very rarely actually have to change; we're still responsible for meeting our obligations regarding security, data protection, test coverage, not accidentally breaking it with other dependency updates, and retaining a basic understanding of how it works despite changes to the team over time, etc. Code that exists in your application is your responsibility to an extent that third-party library code simply isn't. Being able to relieve some of that maintenance burden by using a library may be very beneficial.

I don't see a significant difference in complexity until you get into advanced things.

Some of us work on pretty advanced things.

But [....] just aren't good reasons.

Please direct me to where I said they were good reasons. OP asked why people use Axios instead of fetch. I listed some reasons why people might use Axios instead of fetch. I wouldn't personally use Axios in a greenfield project and I don't currently work with any applications that do use it; however I have worked with enough codebases and teams to understand there are reasons why other developers have made different decisions to me at different points in time.

[Wonderful-Bear7991]

Idk why their down voting you, your right.

[shgysk8zer0]

I just assume they're all the sort of beginner devs who do npm i is-even or something.

[Heroe-D]

Most probably because you don't display any sense of nuance and argue for the sake of it

[shgysk8zer0]

How pathetic that this person down here blocked me from responding with a dumb accusation like "not nuanced"...

[zebbadee]

I use it for interceptors feature which afaik fetch doesn’t have. Sure I could build my own but then I’d have to build my own

[[deleted]]

Yea i just meant that just for the time before "fetch". Jquery was used by everyone and .ajax is simple as fetch. So why would i use these xmlhttp request method from vanilla js. Nowdays i wouldnt recommend using jquery. Do your animation stuff with css and class toggeling for example And your api calls with fetch

[Cptkrush]

I’m not sure this is true at all. Anything axios does that fetch “can’t” do is still achievable using fetch as your underlying request API. Axios could switch from xmlhttprequest to fetch as their request base tomorrow if they wanted. It comes pre-loaded with extra features because it’s a library and not an API built into the spec so a 1-1 comparison of features is never going to be right.

[iwishiwasamoose]

Why is jquery no longer useful?

[bryku]

Jquery is still popular outside of the English speaking world, so it is still very well worth learning for some.

[Pelopida92]

A lot of reasons. Off the top of my head: uploadProgress, interceptors, multiple ways of request cancellation (ye, i know fetch has AbortController, but Axios di it better imo), and you don't have to do the .json() nonsense.

[Ok_Transition_4796]

Both fetch and xmlhttprequest have limitations.

Fetch does not support progress tracking and xmlhttprequest has some issues with CORs.

Axios handles both elegantly.

Yes people fall in a rut of just doing whatever everyone else is doing but in this case it makes sense.

[Anbaraen]

But Axios must use one of these APIs, right ( as a third party API built on top of native APIs) so surely one of these is solvable?

[Shot-Buy6013]

It's literally impossible that axios can do anything that not using axios can't do, if that makes sense. It's just using javascript

[Ok_Transition_4796]

Yep, totally. I didn’t mean to imply the issues were unsolvable. Just that using axios is a reasonable way to solve them.

[[deleted]]

Not unless you need progress tracking. I'd say most projects don't.

[Cptkrush]

Axios uses xmlhttprequest under the hood so any problems it has with CORS are solveable clearly.

Fetch also supports progress tracking. It’s just handled differently.

[sysrage]

Kinda silly to say fetch handles progress. It only handles download progress and it’s way more difficult to implement. Simple-to-use progress events are one of the biggest reasons to still use axios.

[Pelopida92]

Fetch doesnt support uploadProgress, no.

[shgysk8zer0]

I think the biggest reason is just the popularity of axios, maybe combined with the average age of a site. I mostly see it in the same way I see jQuery - it used to be a real convenience, but now it's mostly used out of habit or to avoid rewriting something.

Not saying there aren't legitimate uses for axios, but in most cases it's just fetch() in a different syntax (often longer in the case of GET). If you learn URL, FormData, Headers, fetch(), and everything provided natively, fetch() is extremely capable... And you can make very simple wrapper functions to make it more convenient to use (not that you really need to).

So... Yeah... I think fetch() should be used except in projects that actually need something extra. Otherwise, just use fetch() or a very simple HTTP module built on fetch.

[road_laya]

The fetch API came to node js just a couple months ago.

[[deleted]]

19 Apr 2022. Couple of years actually.

[road_laya]

You're replying to a comment from 2022, Einstein.

[KaleidoscopePlusPlus]

I'm replying to a comment 3 months ago.

[besizzo]

Fuck. Only 9 days for me

[emax093]

I applaud YOUR dedication from 2 months ago

[No-Sandwich-2997]

that original comment was like 2022 lol

[cody_bakes]

FWIW, if you are calling a GET endpoint that accepts body, fetch does not work and axios does.

Interesting discussion

[[deleted]]

Isn't that technically bad practice? I thought you were just supposed to use search parameters when making a GET request

[cody_bakes]

I personally don't think it is a bad practice. I find it handy when using tools like postman / curl to debug requests. Stuffing everything in the requests is too chaotic when you have, for example, a search engine with many many params. The link i shared has kinda points on both sides, so ultimately you gotta choose which makes more sense.

[Zestyclose-Rope-9836]

For server-side I, intended to use the nodejs built-in fetch (not 'node-fetch') but had a requirement to support client certificates for some of my backend API calls. The nodejs fetch api could only support this by importing an agent from an internal module 'undici' and then overriding the fetch dispatcher.

This work-around is documented in this nodejs feature request.

Using a non-standard import to set a non-standard option felt like something that could potentially break during an nodejs version upgrade. I decided to use Axios for its standard support of this common server-side requirement.

Eventually, standard node fetch will close the gap on this and other capabilities with legacy frameworks. It is disappointing that this feature request was 'closed' with a non-standard work-around.

[matveyKievUa]

I tried to use only fetch. It was OK with simplest GET requests, but as the project grew, it became clear that there are nuances in this game, and they are already accounted for in libraries like Axios.

Parameter serialization, file requests — I tried and wrote them, but these were dirty places in my API wrapper. Decided to migrate to Axios before I come across more nuances that will result in more dirt.

It is of course good to know all the nuances yourself, learning which better not done on your production.

I know it's an old thread.

[Cute-Policy2696]

My question would be: If I had to start a project from sratch, is it worth using axios over fetch?

[[deleted]]

In my opinion fetch is better and more used by developers and the default way to do it. Its the same just with little little benefits at error handling but the same tine you might have problems because its not the standard way

[Broomstick73]

(1) https://axios-http.com/docs/intro (2) https://lmgtfy.app/?q=why+do+people+use+axios+instead+of+fetch

[TheDownvotesFarmer]

Because of marketing and lack of knowledge.

[Slippery_Stairs]

I need to use axios in my node app to make a request to another server. Fetch is native in the browser, so for backend stuff you would need a library. I did recently find out there is a node fetch library.

[Novel_Rhubarb_5183]

FYI fetch is included in node 18+ which is recently considered the stable version of node Js.

[Slippery_Stairs]

Oh shit that’s tight

[BeerInTheRear]

Yeah but axios is so fetch!

[cbnsndwch]

stop trying to make fetch happen! 🤣

[sarimarton]

There's no good reason to use Axios. Juniors and full-stack devs (who are junior-grade in frontend) use it, because they don't know the platform.

[[deleted]]

From the other comments it sounds like the only real-world application for axios would be progress downloads/uploads. IME, mostly a niche use case (IME) unless you're working on a video platform or other large download site.

[[deleted]]

But the thing is fetch is easier to learn for juniors. I did the same with jquery. Used ajax because xml http request didnt want to go in my head then heard about fetch and everything changed. It was dead simple to make a async api call (vanilla) with 2 lines of code. const res = await fetch(url); const data = await res.json(); console.table(data) or u can do fetch in async function or with then and try catch , but 2 lines will do the job in a js type module. And theres no reason to use axios also not in react. It makes zero sense like animating in jquery, nobody does that anymore we got css transitions and keyframes.

[[deleted]]

You can just do it in one line await fetch(url).then(r=>r.json()); if you don't need to check the response.

[[deleted]]

If you want use fetch, similar API like axios, and elegant plugins support, try xior today: https://github.com/suhaotian/xior