[zarzavat]

> Depending on Axios suggests the devs don't know how to use fetch.

You could equally say that using fetch means that the developers don't know how to use axios.

They do the same thing, except axios does it a little better, when it doesn't pwn you.

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, unless you need to run on both client and server then of course you use fetch.

[TranquilMarmot]

I usually reach for ky these days since it's an extremely lightweight wrapper over `fetch` - basically just adds a few niceties

https://github.com/sindresorhus/ky

From the readme:

- Simpler API

- Method shortcuts (ky.post())

- Treats non-2xx status codes as errors (after redirects)

- Retries failed requests

- JSON option

- Timeout support

- Upload and download progress

- Base URL option

- Instances with custom defaults

- Hooks

- Response validation with Standard Schema (Zod, Valibot, etc.)

- TypeScript niceties (e.g., .json() supports generics and defaults to unknown, not any)

Of course, this is only for projects where I have to make a lot of HTTP requests to a lot of different places where these niceties make sense. In most cases, we're usually using a library generated from an OpenAPI specification and fall back to `fetch` only as an escape hatch.

[kamranjon]

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).

[junon]

Missing a lot of event hooks that axios/ky give you.

[mattmanser]

Simple examples are interceptors and error handling.

Fetch is one of those things I keep trying to use, but then sorely regret doing so because it's a bit rubbish.

You're probably reinventing axios functionality, badly, in your code.

It's especially useful when you want consistent behaviour across a large codebase, say you want to detect 401s from your API and redirect to a login page. But you don't want to write that on every page.

Now you can do monkey patching shenanigans, or make your own version of fetch like myCompanyFetch and enforce everyone uses it in your linter, or some other rubbish solution.

Or you can just use axios and an interceptor. Clean, elegant.

And every project gets to a size where you need that functionality, or it was a toy and who cares what you use.

[msl]

Forcing everyone to use ourFetch is rubbish, but forcing everyone to use axios is clean and elegant? You might want to elaborate just a little more.

[KronisLV]

ourFetch is more likely to be buggy, unmaintained, undocumented and nobody knows it well because the guy who wrote it left the org 2 years ago and so you have to waste time reading and maintaining it yourself.

Axios is something where you get most of that work done for you by the community for free, and a lot of people know it. As long as you don’t get pwned due to it. Oh and you will actually find community packages that integrate with it, vs ourFetch, which again, nobody knows or even cares that it exists.

Applies to web frameworks, databases and other types of software and dependencies - if you work with brilliant people, you might succeed rolling your own, but for most people taking something battle tested, something off the shelf is a pretty sane way to go about it.

In this case it’s a relatively small dependency so it’s not the end of the world, but it’s the exact same principle.

[DougBTX]

> In this case it’s a relatively small dependency so it’s not the end of the world, but it’s the exact same principle.

An alternative world-view is: "A little copying is better than a little dependency," from https://go-proverbs.github.io

Does become subjective about what "small" and "little" are though.

[KronisLV]

I also agree with this!

I think the ideal model would be being able to depend on upstream code, but being able to review ALL of the actual code changes when pulling in new dependency versions (with a nice UI) and being able to vendor things and branch off with a single command whenever you need it, so you don't have to maintain it yourself by default but it's trivial when you want to.

It's actually surprising that in regards to front end development the whole shadcn approach hasn't gotten more popular. Or anywhere else for that matter, focusing on making code way more easy to maintain, to compile/deploy, with less complexity along the way.

[mattmanser]

Exactly, I completely agree.

It's the difference between using a SQL library and some person on your team writing their own SQL library and everyone having to use it. There's a vast gulf between the two, professionally speaking.

People dissing axios probably suffer from other NIH problems too.

[worble]

> when it doesn't pwn you.

That's a pretty big asterisk though. Taking on a supply chain risk in exchange for reducing developer friction is not worth it in a lot of situations. Every dependency you take increases your risk of getting pwned (especially when it pulls in it's own dependencies), and you seriously need to consider whether it's worth that when you install it.

Don't get me wrong, sometimes it is; I'm certainly not going to create my own web framework from scratch, but a web request helper? Maybe not so much.

[zarzavat]

What the axios attack shows is that even if you stick to sensible, popular packages you can still get pwned if you are not following best practices: set a min age, don't npm install except from a lock file, preferably work in a VM, etc.

Yesterday it's axios, tomorrow it could be react, vite, or typescript. Sticking to only "required" packages won't save you, you have to fix the problem at the root by improving your own security practices. Make the attack impossible, not just unlikely.

[samtrack2019]

I compare this to the request and httplib in python, request library is vastly superior in usability but both do the same..