You may not need axios
Tags: javascript, javascriptlibraries, programming, beginners
Published: 2023-07-08 12:09:27

[Axios](https://axios-http.com/docs/intro) is an awesome library; it offers you niceties and various built in utilities for handling HTTP requests. 

...but you may not need it. The native [`fetch`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) or [`XMLHttpRequest`](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) APIs may be enough for your current needs. 

So, let's go over each of the featured, well, [*features*](https://axios-http.com/docs/intro) of axios and see how many of them are unique to axios.

---

> Before we start a little explanation on the verdicts:
> * **You do not need axios for this 👎**: Means that this feature is something that is already ready to use out of the box with the native APIs
> * **You may not need axios for this 😐**: Means that this feature is something that you can fairly easily implement it yourself with `fetch` or `XMLHttpRequest`
> * **You may need axios for this 👍**: Means that this feature is something that is not very easy to implement it yourself and as such you may want to reach to axios for it

---

### Make XMLHttpRequests from the browser

Good news, you can do that with both `fetch` and `XMLHttpRequests`. 

**Verdict**: You do not need axios for this 👎.

### Make http requests from node.js

Node's "equivalent" for `XMLHttpRequest` is [`http`](https://nodejs.org/api/http.html). Most recent versions of Node have also added support for `fetch` as well. But **if** you have to write server code **and if** you want to write it in Node **and if** you need some level of parity between the front and back end codebases **then** having to only learn and use one API (that of axios) may be useful. 

**Verdict**: You may not need axios for this 😐.

### Supports the Promise API

`fetch` is Promise based. It is also pretty trivial to make a Promise wrapper for `XMLHttpRequest` if you so wish.

**Verdict**: You do not need axios for this 👎.

### Intercept request and response

If you know you will have to do this and you do not want to build this functionality yourself then having a built in way to do it is surely useful.

**Verdict**: You may need axios for this 👍.

### Transform request and response data

Same as above, if you know you will need this and you do not want to built it yourself axios is a good choice.

**Verdict**: You may need axios for this 👍.

### Cancel requests

You can do this with both `fetch` and `XMLHttpRequest`

**Verdict**: You do not need axios for this 👎.

### Timeouts

Keeping in mind you can cancel requests with both `fetch` and `XMLHttpRequest` it is not so difficult to "timeout" a request using `setTimeout`. But, as always, **if** you know you will be requiring this functionality a lot **and if** you do not want to spent any time at all to implement it yourself **then** you can use axios I guess. But come on, it's just a `setTimeout` 😅

**Verdict**: You may not need axios for this 😐.

### Query parameters serialization with support for nested entries

[`URLSearchParams`](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams) exists. Yes, if you are using TypeScript it may be a little stingy because it actually requires that you pass a `Record<string, string>` object (even though passing something like `Record<string, number>` will also work in reality) but overall it's easy to use and it's a native way to manage your query params.

**Verdict**: If you use TypeScript and you are ok with having to pass only `Record<string, string>` objects to `URLSearchParams` you do not need axios for this 👎.

### Automatic request body serialization

While not "automatic", all you need to do when you send a request is to match the data you are sending with the appropriate [`Content-Type`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) header. Axios can automatically transform plain JS objects to `FormData` objects if you define the request `Content-Type` header as `multipart/form-data` which is nice, but why not just try to send what your API expects?

**Verdict**: You may not need axios for this 😐.

### Posting HTML forms as JSON

This had me quite confused. Posting a form as JSON is not a task that befalls on axios, rather the user, who has to collect the form data and convert them to a suitable format for sending them as `application/json` instead of `multipart/form-data`. Really not sure what they mean here, but from what I understand 👇

**Verdict**: You do not need axios for this 👎.

### Automatic JSON data handling in response

Not sure what is automatically handled in the response's JSON data here. If someone knows feel free to chime in the comments.

**Verdict**: ??
 
### Progress capturing for browsers and node.js with extra info (speed rate, remaining time)

This is hands down one of the best features of axios. While this not very difficult to implement it yourself using `XMLHttpRequest`, you will not be so lucky if you have chosen to go with `fetch` and do not want to be mixing them up. If you need this functionality the fact that it's ready to use here out of the box is a godsend; we are not talking about a `setTimeout` implementation here.

**Verdict**: You may need axios for this 👍.

### Setting bandwidth limits for node.js

This is another one of those things where you probably do not want to implement yourself from scratch, because it is not a trivial implementation. If you need this functionality you will probably appreciate the fact that someone already implemented this for you.

**Verdict**: You may need axios for this 👍.

### Client side support for protecting against XSRF

All this does is read a [`CSRF`](https://en.wikipedia.org/wiki/Cross-site_request_forgery) related cookie from your environment and pass it along with the request headers ([ref](https://github.com/axios/axios/issues/2327)). Not something you cannot do yourself easily, but automating this is nice.

**Verdict**: You may not need axios for this 😐.

## Overall

I guess the point I want to make with this post is to _always weight your needs and your options and decide based on them_. If your needs change then reconsider your options and change them if needed.

Do not use a tool blindly just because you saw it in a StackOverflow answer or a tutorial or simply because it's the flavour of the month.

This is not something specific to axios. I like axios, I have used it a lot during my career, I do not have any problem with it; it's a fine tool that does what it does very well. Axios is just a nice case to analyse in this way.

Thank you for reading 🎉