3 ms·

Let me make the argument against axios. Even if you are happy, your users may not. Axios (btw still on version 0.x despite being one of the older javascript pa

Let me make the argument against axios. Even if you are happy, your users may not. Axios (btw still on version 0.x despite being one of the older javascript packages, means it can introduce breaking changes without any warning, think about that) adds 4.4kB (minified+gzipped) to your bundle. Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!). If all you need to GET or POST, without any special needs, the w3c fetch function is definitely better for your users.

adventured 6y ago
> adds 4.4kB (minified+gzipped) to your bundle ... Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!) A few times? You're suggesting doing that 50 or 100 times. Adding 4.4kb an actual few times is meaningless for the end user.
- wereHamster 6y ago
  axios is actually not that bad, in terms of size. There are definitely worse dependencies you can have. However to me the fact that someone decided to use axios in the frontend makes me cautious about everything else. Are they perhaps also using lodash (70kB) for just that one function? Or are they using ramda and lodash at the same time (or any other two packages that contain duplicate functionality)? Don't get me wrong, there are valid reasons to use axios, and I don't have a problem if you communicate those clearly. But I believe few developers make a conscious decision about the tradeoffs, most developers simply dgaf.
heipei 6y ago
My argument for using axios is developer ergonomics. There are a few libraries that I use both in the frontend and the backend, for which I gladly accept the increased bundle size: axios, lodash, moment, Q. My users get the benefit in me being able to ship features faster because I don't have to constantly keep up with which feature ships in which browser version etc. I also found the fetch API horrendous to use. It's a tradeoff I'm willing to make.
- whycombagator 6y ago
  Do you take on the entire of Lodash as a dependency? If so, do you use any of the Lodash features not described here?[0] If you use more than described, or if a specific Lodash feature is more performant, you can selectively import[1]. [0] https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore https://github.com/you-dont-need/You-Dont-Need-Lodash-Unders... [1] https://www.npmjs.com/search?q=keywords:lodash-modularized https://www.npmjs.com/search?q=keywords:lodash-modularized
- brlewis 6y ago
  When you found the fetch API horrendous were you using async/await? They make it not horrendous. You don't have to keep up with which feature ships in which browser; that's what browserslist is for. https://github.com/facebook/create-react-app/blob/master/packages/react-app-polyfill/README.md https://github.com/facebook/create-react-app/blob/master/pac...
sdfhbdf 6y ago
In the end fetch was supposed to supersede all these libraries. Unfortunately in cases like this seems like Node.js, and JavaScripts's lack of standard library really shows. Every developer will use whatever either they encounter first because they don't feel like learning a new shiny library or whatever is the most comfortable and maybe not right. NPM has its positives - discoveriblity being one for sure but also its drawbacks - million ways of accomplishing the same thing. Axios after fetch being standard everywhere starts to feel like jQuery after document.querySelectorAll being available everywhere.
ng12 6y ago
> the w3c fetch function is definitely better for your users Sure, unless your users are desktop IE11 users. They won't care about 4.4kb but they'll definitely care about a broken page :)

adventured 6y ago

> adds 4.4kB (minified+gzipped) to your bundle ... Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!) A few times? You're suggesting doing that 50 or 100 times. Adding 4.4kb an actual few times is meaningless for the end user.

wereHamster 6y ago
axios is actually not that bad, in terms of size. There are definitely worse dependencies you can have. However to me the fact that someone decided to use axios in the frontend makes me cautious about everything else. Are they perhaps also using lodash (70kB) for just that one function? Or are they using ramda and lodash at the same time (or any other two packages that contain duplicate functionality)? Don't get me wrong, there are valid reasons to use axios, and I don't have a problem if you communicate those clearly. But I believe few developers make a conscious decision about the tradeoffs, most developers simply dgaf.

heipei 6y ago

My argument for using axios is developer ergonomics. There are a few libraries that I use both in the frontend and the backend, for which I gladly accept the increased bundle size: axios, lodash, moment, Q. My users get the benefit in me being able to ship features faster because I don't have to constantly keep up with which feature ships in which browser version etc. I also found the fetch API horrendous to use. It's a tradeoff I'm willing to make.

whycombagator 6y ago
Do you take on the entire of Lodash as a dependency? If so, do you use any of the Lodash features not described here?[0] If you use more than described, or if a specific Lodash feature is more performant, you can selectively import[1]. [0] https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore https://github.com/you-dont-need/You-Dont-Need-Lodash-Unders... [1] https://www.npmjs.com/search?q=keywords:lodash-modularized https://www.npmjs.com/search?q=keywords:lodash-modularized
brlewis 6y ago
When you found the fetch API horrendous were you using async/await? They make it not horrendous. You don't have to keep up with which feature ships in which browser; that's what browserslist is for. https://github.com/facebook/create-react-app/blob/master/packages/react-app-polyfill/README.md https://github.com/facebook/create-react-app/blob/master/pac...

sdfhbdf 6y ago

In the end fetch was supposed to supersede all these libraries. Unfortunately in cases like this seems like Node.js, and JavaScripts's lack of standard library really shows. Every developer will use whatever either they encounter first because they don't feel like learning a new shiny library or whatever is the most comfortable and maybe not right. NPM has its positives - discoveriblity being one for sure but also its drawbacks - million ways of accomplishing the same thing. Axios after fetch being standard everywhere starts to feel like jQuery after document.querySelectorAll being available everywhere.

ng12 6y ago

> the w3c fetch function is definitely better for your users Sure, unless your users are desktop IE11 users. They won't care about 4.4kb but they'll definitely care about a broken page :)