-
-
Notifications
You must be signed in to change notification settings - Fork 662
doc: undici vs fetch #4245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: undici vs fetch #4245
Conversation
I'm not sure if this is what we want or if all the information is up to date, but I'm happy to iterate on this and make the necessary changes. Here's a link of some of the sources I used: |
README.md
Outdated
|
||
**Cons:** | ||
- Additional dependency to manage | ||
- Larger bundle size if used in client-side code |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a thing, you should not be using either in client-side frontend code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the portion about client-side code. Let me know if I should scrap the point entirely
README.md
Outdated
#### Use Built-in Fetch When: | ||
- You want zero dependencies | ||
- Building isomorphic code that runs in browsers and Node.js | ||
- You need standard Web API compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This point is incorrect, they offer the same (circa) level of web standard compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, updated.
README.md
Outdated
|
||
1. **`undici.request()`** - Fastest, most efficient | ||
2. **`undici.fetch()`** - Fast, with Web API compatibility | ||
3. **Built-in `fetch()`** - Good performance, standard compliance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 and 3 should be essentially identical
👍 This extra detail is great! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@mcollina can we land this? |
- You want zero dependencies | ||
- Building isomorphic code that runs in browsers and Node.js | ||
- Simple HTTP requests without advanced configuration | ||
- You're okay with the undici version bundled in your Node.js version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this last bullet point isn’t quite right.
Because it’s not “your Node.js“ version but rather, the consumer’s Node.js version.
Like if you publish to npm, it could be running under any Node.js version that the user decides to execute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@styfle can you send some updated text?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This relates to...
#4066
Changes
Added section in documentation to highlight undici vs fetch differences and usecases
Status