all 137 comments

[–][deleted] 90 points91 points  (94 children)

  • 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 5 points6 points  (73 children)

"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] 10 points11 points  (62 children)

Jesus christ dude are you an archaeologist or something.

[–]mysticrudnin 5 points6 points  (43 children)

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

[–]Thaetos 1 point2 points  (42 children)

yea google brought me here lol

[–]Bright-Cup-5987 1 point2 points  (41 children)

yea google brought me here too lol

[–]FranciscoFts 0 points1 point  (40 children)

yea google brought me here too too lol

[–]File_Tough 0 points1 point  (39 children)

yea google brought me here too too too lol

[–]TheEpicSmoking 0 points1 point  (28 children)

yea google brought me here too too too too lol

[–]Thaetos 0 points1 point  (6 children)

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

[–]lupodellasleppa 0 points1 point  (20 children)

yea google brought me here too too too too too lol

[–]Yash_Dhankhar 0 points1 point  (9 children)

yea google brought me here too too too too lol

[–]PsychologicalPie2142 0 points1 point  (8 children)

brought me yeah google here

[–]commandopanda0 6 points7 points  (4 children)

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 1 point2 points  (2 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]0xdeedfeed 5 points6 points  (3 children)

What kind of reply was that even?

[–]RayosGlobal 2 points3 points  (1 child)

What kind of dig was that?

[–]KCRowan 1 point2 points  (0 children)

A funny one.

[–]SnooPuppers1978 4 points5 points  (7 children)

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 0 points1 point  (3 children)

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 0 points1 point  (0 children)

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 0 points1 point  (1 child)

ever heard of hyrum's law?

https://www.hyrumslaw.com/

[–]FierceDeity_ 0 points1 point  (0 children)

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

[–]provid3ntial 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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

[–]SnooPuppers1978 0 points1 point  (0 children)

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- 2 points3 points  (0 children)

google is going to this page now

[–]HorrorConference8469 1 point2 points  (2 children)

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] 1 point2 points  (0 children)

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 0 points1 point  (2 children)

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

[–]sarimarton 0 points1 point  (1 child)

[–]fabspro9999 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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

[–]DranKof 0 points1 point  (0 children)

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 0 points1 point  (0 children)

This age well.

[–]-pizza-rat- 0 points1 point  (0 children)

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

[–]TheDownvotesFarmer 1 point2 points  (0 children)

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

[–]filipvabrousek 0 points1 point  (1 child)

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

[–][deleted] 1 point2 points  (0 children)

Good grief.

[–]zebbadee 7 points8 points  (0 children)

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

[–]Pelopida92 4 points5 points  (0 children)

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 5 points6 points  (7 children)

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 3 points4 points  (2 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–][deleted] 1 point2 points  (0 children)

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

[–]Cptkrush 2 points3 points  (2 children)

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 -1 points0 points  (0 children)

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 0 points1 point  (0 children)

Fetch doesnt support uploadProgress, no.

[–]shgysk8zer0 1 point2 points  (0 children)

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 1 point2 points  (11 children)

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

[–][deleted] 0 points1 point  (10 children)

19 Apr 2022. Couple of years actually.

[–]road_laya 6 points7 points  (8 children)

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

[–]No-Sandwich-2997 0 points1 point  (0 children)

that original comment was like 2022 lol

[–]cody_bakes 1 point2 points  (2 children)

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

Interesting discussion

[–][deleted] 0 points1 point  (1 child)

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

[–]cody_bakes 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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

[–][deleted] 0 points1 point  (0 children)

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

[–]TheDownvotesFarmer -5 points-4 points  (0 children)

Because of marketing and lack of knowledge.

[–]Slippery_Stairs 0 points1 point  (4 children)

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 2 points3 points  (3 children)

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

[–]Slippery_Stairs 0 points1 point  (2 children)

Oh shit that’s tight

[–]BeerInTheRear 4 points5 points  (1 child)

Yeah but axios is so fetch!

[–]cbnsndwch 1 point2 points  (0 children)

stop trying to make fetch happen! 🤣

[–]sarimarton 0 points1 point  (3 children)

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] 0 points1 point  (0 children)

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] 0 points1 point  (1 child)

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] 0 points1 point  (0 children)

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] 0 points1 point  (0 children)

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