Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] what advantage does axios give us over fetch? EOM #314

Closed
es6Test opened this issue May 5, 2016 · 16 comments
Closed

[Question] what advantage does axios give us over fetch? EOM #314

es6Test opened this issue May 5, 2016 · 16 comments

Comments

@es6Test
Copy link

es6Test commented May 5, 2016

No description provided.

@mzabriskie
Copy link
Member

Overall they are very similar. Some benefits of axios:

  • Transformers: allow performing transforms on data before request is made or after response is received
  • Interceptors: allow you to alter the request or response entirely (headers as well). also perform async operations before request is made or before Promise settles
  • Built-in XSRF protection

@niftylettuce
Copy link

I wrote a fetch implementation, which was inspired by axios, superagent, and request here https://github.com/glazedio/frisbee. I really do wish axios used fetch though!!! I love this package.

@mzabriskie
Copy link
Member

@niftylettuce I started this project before fetch was a thing. Haven't really seen any justification in refactoring. What benefit would using fetch provide?

@rockallite
Copy link

rockallite commented Jul 14, 2016

  • fetch has yet to provide a standard way of aborting a request. Therefore, there's no way to implement connection timeout. (#27, #447)

  • fetch has failed to provide an API to set response timeout. (#20)

    • ...which means that you'll have to wait until the end of the response or the occurrence of a network error.

    • ...or, use setTimeout or Promise.race to manually reject the returned promise if you need a timeout. And it has a tiny side effect (#175):

      mislav commented on 29 Jul 2015
      Also note that with the above implementation, even if the timeout happens, the original request won't be aborted because we don't have an API to abort fetch requests. Instead, the request will complete in the background but its response will get discarded.

  • See the comments of this blog post. And I'm totally agree with the following one:

    J W
    Although the standard loosely talks about timeout’s, they never explain as to how you would specify one either. Unfortunately, a complete deal breaker for any use cases that I would use it for.
    March 17th, 2015 at 15:02

  • Notice that all the above opinions are based on fetch (or its browser polyfill), not node-fetch.

@es6Test
Copy link
Author

es6Test commented Jul 14, 2016

I see, I'm surprised the fetch guys haven't sorted this yet.

@GanbilegBor-minted
Copy link

Also as of right now fetch is not supported on any Safari and EI versions (scroll down), unless you want to add a polyfill. And unfortunately even if you're using babel fetch polyfill doesn't come with it so it's a little bit of extra work to add a polyfill like this one.

@larsnystrom
Copy link

Fetch does not support upload progress.

Perhaps the information in this thread could be added to the readme? I think there are plenty of people who choose fetch over xhr just because it's the shiny new thing, and then have to refactor a bunch of code as they realise fetch doesn't support as many use cases as xhr does.

@pke
Copy link

pke commented Nov 3, 2016

@larsnystrom I also just now discovered axios because of apisauce using it. I wondered why it didn't use fetch. I am using fetch because its the default for any reactjs sample out there.
But after reading this comparison here I'll ditch fetch because I want timeouts and always wondered why fetch does not have it. And if you see the referenced issues over there, they are so old I doubt they will ever end up in fetch.

So I think a comparison of two libraries on the front pages' readme would help people to choose one over the other.

@dmt0
Copy link

dmt0 commented Nov 24, 2016

@mzabriskie One reason you might want to use fetch is if you want to make an offline-first app using Service Worker API: https://developers.google.com/web/fundamentals/getting-started/primers/service-workers

With fetch you can add event listeners for Service Worker to intercept. Haven't found a way to do that with XHR yet.

Can fetch support be added axios as an Adapter?

@Haocen
Copy link

Haocen commented Aug 9, 2017

According to http://caniuse.com/#search=fetch , the native support for fetch is fantastic now.

@niftylettuce
Copy link

Just FYI - my axios inspired implementation (that uses fetch) has a new link / repository at https://github.com/joinspontaneous/frisbee! The only downside I think is that fetch API won't let you stop/cancel a request in process.

@vzaidman
Copy link

vzaidman commented Nov 5, 2017

@niftylettuce and no "upload progress" right?

@larsnystrom
Copy link

@niftylettuce No, not always. You need permissions to run a WebSocket-server on your host. That’s not always a possibility. Many people have sites on cheap hosts with LAMP-stacks. Even when you have full control of your web host, the fact that you have to change your server-side code to deal with file uploads just because you decided to use fetch over XHR in the client should give paus for thought.

@gustawdaniel
Copy link

gustawdaniel commented Mar 17, 2018

There is great article about this:

https://medium.com/@thejasonfile/fetch-vs-axios-js-for-making-http-requests-2b261cdd3af5

  • fetch is better for low level sollution eg. streaming
  • axios is better for typical web applications

@vzaidman
Copy link

not so great since it discusses only one minor difference as far as i see

@ruchernchong
Copy link

ruchernchong commented Nov 19, 2018

Axios interceptors for me. That is a breeze to setup configuration for global contents.

@axios axios locked and limited conversation to collaborators May 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests