Comment by afavour
24 days ago
Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.
24 days ago
Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.
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.
[dead]
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?
2 replies →
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
3 replies →
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).
> `fetch` is the official replacement for axios.
No. Axios is still maintained. They have not deprecated the project in favor of fetch.
4 replies →
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.
[dead]