Axios, like Express, is something I'm shocked to see used in any modern codebase. I loved both in the 2010s. In JS/TS-land there are much simpler and better options these days. Depending on Axios suggests the devs don't know how to use fetch. I can't think of another reason it would be a necessary dependency
> Depending on Axios suggests the devs don't know how to use fetch.<p>You could equally say that using fetch means that the developers don't know how to use axios.<p>They do the same thing, except axios does it a little better, when it doesn't pwn you.<p>Axios predates the availability of fetch in node by 2 years, and fetch has never caught up with axios so there was no reason to switch to fetch, <i>unless</i> you need to run on both client and server then of course you use fetch.
In what ways has fetch never caught up to axios? I have not encountered a situation where I could not use fetch in the last 5 years so I'm just curious what killer features axios has that are still missing in fetch (I certainly remember using axios many moons ago).
I compare this to the request and httplib in python, request library is vastly superior in usability but both do the same..
I wouldn't go that far. Right tool for the job as always. Axios offers a lot over fetch for all but the simplest use cases plus you get to take advantage of the ecosystem. Need offline, axios-cache-interceptor already exists. Sure you can do all of those things with fetch but you need more to go with it taking you right back to just using axios. Also is no one annoyed that you can't replay fetch like the xhr? Same with express: solves a problem reliably.
If you want a fully built out network layer, with auth, logging, monitoring, policies, etc, then `fetch` doesn't really help. Axios and other libraries provide much more for building that sort of framework.
Any sufficiently competent typescript developer can build out an adhoc wrapper (that just inherits the type definition and passes along whatever it is passed after altering it however needed) in under a hour. It doesn't scale in the sense that you don't expose a configuration, but config as code is king.<p>(Source: have built out much more scuffed variants of this than the one I just described like <a href="https://github.com/boehs/ajar" rel="nofollow">https://github.com/boehs/ajar</a>)<p>I guess a LLM can do as well. Although that's not something I'm quite ready to admit.
I've wrapped fetch a few times but i don't think I'd blame someone if they got tired of wrapping it and wanted a consistent interface across all the projects they work on.
Keep developing it. Your taste and judgement matter
I do "just use fetch" nowadays -- but I have to say, axios definitely has better ergonomics than fetch, especially for calling APIs.
I drag a tiny fetch wrapper around with error/json handling, timeouts and basic interceptor support. It doesn't cover everything axios does but it's nice enough and I haven't had to touch it in a couple years.<p>For reference: <a href="https://github.com/sampullman/fetch-api/blob/main/lib/fetchApi.ts" rel="nofollow">https://github.com/sampullman/fetch-api/blob/main/lib/fetchA...</a>
When the vulnerability was announced, it took me two minutes to one-shot convert an entire legacy project from axios to fetch (it already wrapped api calls neatly), react cra to vite, update all dependencies, convert to deep imports to reduce bundle size and get zero npm warnings while fetching coffee. There is just no excuse to use it.
jQuery is still useful too. May you never work in heathcare / government / defense where you need to support legacy browsers far past their expiration date.
ChatGPT in general recommends axios over fetch. (At least it did about 2 months ago)
What's wrong with Express?
Several newer alternatives that outperform it on Node, like Hono
Just slow and convoluted internals due to the accumulation of cruft over time
What’s wrong with express?