It doesn't matter. We pulled axios out of our codebase, but it still ends up in there as a child or peer from 40 other dependencies. Many from major vendors like datadog, slack, twilio, nx (in the gcs-cache extension), etc...

Every time I'm reminded of this article about package managers. https://www.gingerbill.org/article/2025/09/08/package-manage...

Yep, got stung because a bunch of things still pull in axios even though we don't use it.

Serverless framework up until late yesterday also.

People use axios or ky because with fetch you inevitably end up writing a small wrapper on top of it anyway.

Fetch has also lacked support for features that xhr has had for over a decade now. For example upload progress. It's slowly catching up though, upload progress is the only thing I'd choose xhr for.

You can pipe through a TransformStream that counts how many bytes you've uploaded, right?

That would show how quickly the data is passing into the native fetch call but doesn’t account for kind of internal buffer it might have, network latency etc

That is a way to approximate it, though I'd be curious to know the semantics compared to xhr - would they both show the same value at the same network lifecycle of a given byte?

Some might say the tradeoff of writing a small wrapper is worth it given what’s been demonstrated here.

Yeah but what about other deps like db drivers?

In my experience people feel the need to wrap axios too.

These are the kind of people I hope AI replaces

I have never consciously wrapped Axios or fetch, but a cursory search suggests that there was a time when it was impossible for either to force TLS1.3. It's easy to imagine alternate implementations exist for frivolous reasons, but sometimes there are hard security or performance requirements that force you into them.

AI was trained on Axios wrappers, so it's just going to be wrappers all the way down. Look inside any company "API Client" and it's just a branded wrapper around Axios.

Because native fetch lack retries, error handling is verbose, search and body serialization create ton of boilerplate. I use KY http client, small lib on top of fetch with great UX and trusted maintainer.

I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

> I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

Nor is fetch a good client-side API either; you want progress indicators, on both upload and download. Fetch is a poor API all-round.

You can pass to `fetch` an `AbortSignal` like `AbortSignal.timeout(5000)` as a simple and easy guard.

If you also want to guard on size, iterating the `response.body` stream with for/await/of and adding a counter that can `abort()` a manual `AbortSignal` is relatively straightforward, though sounds complicated. You can even do that as a custom `ReadableStream` implementation so that you can wrap it back into `Response` and still use the `response.json()` shortcut. I'm surprised I'm not seeing a standard implementation of that, but it also looks straightforward from MDN documentation [1].

[1] https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...

Browser fetch can lean on the fact that the runtime environment has hard limits per tab and the user will just close the tab if things get weird. on the server you're right

Hm, I don't think axios would do much better here. `fetch` is the official replacement for axios. If both are flawed that's another topic

Axios has maxContentLength and maxBodyLength options. I would probably go with undici nowadays though (it also has maxResponseSize).

I'm not saying that axios is unmaintained, I'm saying that if you want something like axios from the standard lib, fetch is the closest thing you get to official

Sure but Axios determine what the official replacement for Axios is.

It's not deprecated, it's obsoleted.

Node fetch is relatively new. Wasn't marked stable until 2023, though I've used it since like 2018.

It doesn't have a need _now_. Axios is more than 10 years old now, and even before axios other libraries did the same utility of making requests easier

Browsers too.

It’s not needed anymore.