You may not need axios, just like you do not need any luxuries in life.
But why would you avoid axios?
Axios provides a much better api / dev experience calling http endpoints. That's a plus.
What are the downsides, except bundle size ?
it's not about when it throws, it's how it handles errors. It hides the response in error.response.data, which becomes a big issue when dealing with typescript.
And I just don't like writing error.response?.data?.whatever in general. I generally prefer dealing with Response.
And there's no way to conditionally tell axios to not parse responses. One big reason to not use axios is because of the all or nothing behaviour. You have build a client for each scenario (which is unrealistic)
You can type axios, example: await axios.post<EventType[] | { errorMessage: string }>(urlApiCmdPublic, cmd)
so I would not count that as a downside. Fetch in comparison does not have any types at all.
"no way to conditionally tell axios to not parse responses" - that's a fair point,
but its relevant only if using some non-http/rest APIs - which to be fair should be pretty rare.
I agree with you, that axios is mostly designed to consume http/rest apis with good developer experience
and having the niche use-case of calling lower level binary apis is best served using lower level tools like fetch.
await axios.post<EventType[] | { errorMessage: string }>(urlApiCmdPublic, cmd) only works for non-error responses.
Fetch in comparison does not have any types at all
Not exactly true, you get aResponse which makes sense. And then you can convert to json and do validation i.e using zod schema.parse(await response.json()) to get a concrete type. Which is a much better approach than what axios offers
Thanks for your feedback. I agree with you on the DX part.
I know the article says "axios" but it's really about not bringing in dependencies unless the DX is so poor you'd throw your laptop out if you don't bring in a library.
Picking on axios one more time: axios have three dependencies, one of which is form-data. We don't need this dependency in the browser because the browser natively supports form data, and you also don't need it in nodejs from node 18+. Form data also have 3 other dependencies that also have their dependencies. The dependency tree goes on and on, and at any point, one of the maintainers might decide to hit the kill switch on the project. For example, form-data's last update was three years ago, but it currently has 113 open issues.
All that dependency when what most(not all) web applications out there do is fetch data and map to JSX or render to HTML, listen to events, submit data, update state, and repeat.
1.
I think its okay for library to not get any updates if the protocol (multipart, like in the case of form-data) is stable.
Do all libraries have to release new versions just for appearance sake?
Axios has many issues listed github.com/axios/axios/issues?q=is...
but no bugs (mostly feature requests and questions about edge cases)
and seems very safe / stable to use.
I can understand your strife to reduce dependencies, but that are the alternatives ? Write http data fetching libraries yourself
or suffer poor DX because of raw XMLHttpRequest / fetch.
2.
I have looked a bit more at http client libraries
I see. I think the author (and I agree) is on the line of "90% of people don't need adapters, don't need base paths or have them covered elsewhere". I think that for 9 out of 10 developers, axios is 57kb of "nothing I need".
I imagine that the adapters are probably very handy, but are also probably very specific and catered for the minority, not the majority.
So yes, I think you are doing the right thing considering fetch() as the primary tool here. If you need interception of request or response, that's something that can be easily done in far less than 57kb.
Cheers!
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You may not need axios, just like you do not need any luxuries in life.
But why would you avoid
axios?Axios provides a much better api / dev experience calling http endpoints. That's a plus.
What are the downsides, except bundle size ?
axios bundle size is 57 kB -> 21.8 kB (gzip)
bundlejs.com/?q=axios%401.5.1
One reason to avoid axios, difficult to handle errors.
How is it more difficult to handle than fetch?
You can even overwrite/define then it throws errors
pipedream.com/community/t/faq-how-...
it's not about when it throws, it's how it handles errors. It hides the response in error.response.data, which becomes a big issue when dealing with typescript.
How is accessing the response with
error.response.datain typescript a big problem?When using
asyn/awaityou loose all types, so you have to doAnd I just don't like writing
error.response?.data?.whateverin general. I generally prefer dealing withResponse.And there's no way to conditionally tell axios to not parse responses. One big reason to not use axios is because of the all or nothing behaviour. You have build a client for each scenario (which is unrealistic)
You can type axios, example:
await axios.post<EventType[] | { errorMessage: string }>(urlApiCmdPublic, cmd)so I would not count that as a downside. Fetch in comparison does not have any types at all.
"no way to conditionally tell axios to not parse responses" - that's a fair point,
but its relevant only if using some non-http/rest APIs - which to be fair should be pretty rare.
I agree with you, that
axiosis mostly designed to consume http/rest apis with good developer experienceand having the niche use-case of calling lower level binary apis is best served using lower level tools like
fetch.await axios.post<EventType[] | { errorMessage: string }>(urlApiCmdPublic, cmd)only works for non-error responses.Not exactly true, you get a
Responsewhich makes sense. And then you can convert to json and do validation i.e using zodschema.parse(await response.json())to get a concrete type. Which is a much better approach than what axios offersHi @adaptiveshieldmatrix
Thanks for your feedback. I agree with you on the DX part.
I know the article says "axios" but it's really about not bringing in dependencies unless the DX is so poor you'd throw your laptop out if you don't bring in a library.
Picking on
axiosone more time: axios have three dependencies, one of which is form-data. We don't need this dependency in the browser because the browser natively supports form data, and you also don't need it in nodejs from node 18+. Form data also have 3 other dependencies that also have their dependencies. The dependency tree goes on and on, and at any point, one of the maintainers might decide to hit the kill switch on the project. For example, form-data's last update was three years ago, but it currently has 113 open issues.All that dependency when what most(not all) web applications out there do is fetch data and map to JSX or render to HTML, listen to events, submit data, update state, and repeat.
1.
I think its okay for library to not get any updates if the protocol (multipart, like in the case of form-data) is stable.
Do all libraries have to release new versions just for appearance sake?
Axios has many issues listed
github.com/axios/axios/issues?q=is...
but no bugs (mostly feature requests and questions about edge cases)
and seems very safe / stable to use.
I can understand your strife to reduce dependencies, but that are the alternatives ? Write http data fetching libraries yourself
or suffer poor DX because of raw XMLHttpRequest / fetch.
2.
I have looked a bit more at http client libraries
Here seems to be a good comparison
github.com/sindresorhus/got#compar...
Following your main grip against axios -> ky seems to be the next best choice for http clients in the browser
github.com/sindresorhus/ky
With a bundle size of only 9.12 kB -> 3.23 kB gzip
https://bundlejs.com/?q=ky%401.1.0&treeshake=%5B*%5D
thanks. Would check the links out
I would be very interested in seeing exactly what you refer to. What am I gaining, exactly, for the extra 57kb?
The top things I can think of:
json()(in comparison to fetch) to get the dataWith the release of
fetchthis list got much shorter...I think I'm slowly coming around to using fetch on the browser as well
I see. I think the author (and I agree) is on the line of "90% of people don't need adapters, don't need base paths or have them covered elsewhere". I think that for 9 out of 10 developers,
axiosis 57kb of "nothing I need".I imagine that the adapters are probably very handy, but are also probably very specific and catered for the minority, not the majority.
So yes, I think you are doing the right thing considering
fetch()as the primary tool here. If you need interception of request or response, that's something that can be easily done in far less than 57kb.Cheers!