Good that some people are happy about this, but it really is pointless to post a link to "lib: add fetch" followed by code diffs. HN should have a requirement that there be an actual post, rather than a discussion starter for those in a particular community. All you'd have to do is type in a brief text post with an explanation and then link to the code diffs for those interested.
Fetch API has landed into Node.js
61–70 of 210 posts
Re: Fetch API has landed into Node.js
#62Re: Fetch API has landed into Node.js
#63Earlier quoted context omitted.
my guess is that this adds stuff to the global object which has backwards compatibility concerns. And with every public API: Once you add it, you can't really hope to ever change it and even bug-fixes could be breaking some user's code (because they relied on the bug), so you have to be very careful to ship your public API as bug-free as possible.
Yes I could imagine and I have experience of developing apis with "bugs" that you kind of need to keep since people come to depend on it working a certain way. But I can't help to feel like Node is progressing kind of slow compared to other languages / tools. This is just a personal impression from a bystander who is not really into the actual progression though. I have a feeling that node used to push new features a…
I think some of it is because Node doesn’t have very many ways to let people know about potentially breaking changes. A compiler (like Elixir) has an opportunity to communicate potential breaking changes to the user before the program actually runs, and a static type system (like Rust) makes it easy to detect such broken code and reject it outright instead of silently changing behavior. It’s harder for Node: where would the diagnostic even go? The console? Some apps use Curses, so this will break them, and many of them send their own logs through something other than the console, so nobody’s actually watching it.
Node also isn’t actually a language, so there’s a lot of stuff that Node developers get in new version, but it’s actually being done in the V8 project.
Re: Fetch API has landed into Node.js
#64Earlier quoted context omitted.
Is there any chance to break spec and allow manual redirect handling? the fetch API makes a lot of sense in a browser, but imo this is a pretty crucial feature that undici's implementation lacks. [0] Deno decided to break spec [1][2] so the following code works fine: fetch('https://httpbin.org/status/302', {redirect: 'manual'}) .then(res => console.log(res.status, res.headers)) In undici this will succeed but with re…
A better idea would be to replace / improve the fetch spec. Handle redirects, set JSON as the default request content type, encode URI components for users, decode response bodies with JSON headers as JS objects, etc. Right now most developers either write their own library to do these things on top of fetch or another HTTP client or use a third party library from npm. A new standard would allow us to make http reque…
Why is this being down voted? This comment seems to be making a reasonable case.
In case you disagree, you may want to reply why instead of down voting.
Re: Fetch API has landed into Node.js
#65My biggest issue with node when I was working on it briefly was I couldn't do the 'import' statements like wepback. Are they supported too now? I'm not a web developer so I had a very hard time understanding why there are so many different type of imports in JavaScript like require, import, umd, amd, etc and which one works in browser and which one works in node? Also why do so many libraries have this strange 5 line…
Those have been supported for several years now :) You need to tell Node to use the format by either naming your file `.mjs` or setting `"type": "module"` in your `package.json` file. > Also why do so many libraries have this strange 5 line header code for this umd, amd, business. Is that to make their packages work with nodejs? That's just old for "adapt the module system" from the old days and libraries just didn't…
> either naming your file `.mjs`
But why? This makes it much harder to ensure that identical code works in browser and nodejs, to the point where I sometimes just can't use nodejs. And I don't use package.json, so having to name files ".mjs" is a really painfull restriction.
Re: Fetch API has landed into Node.js
#66Ive used Fetch in the past, great lib. I'm curious why Node core has decided to make this an official part of Node? From one perspective there could be a hard argument that this should never be a part of Node as it is an external library and not a building block of the language? Almost feels like feature creep for the core language? I know that's not the intent, but wanting to understand the logic behind this decision :)
Re: Fetch API has landed into Node.js
#67Ive used Fetch in the past, great lib. I'm curious why Node core has decided to make this an official part of Node? From one perspective there could be a hard argument that this should never be a part of Node as it is an external library and not a building block of the language? Almost feels like feature creep for the core language? I know that's not the intent, but wanting to understand the logic behind this decisio…
Fetch is a standard browser API.
Re: Fetch API has landed into Node.js
#68Earlier quoted context omitted.
A better idea would be to replace / improve the fetch spec. Handle redirects, set JSON as the default request content type, encode URI components for users, decode response bodies with JSON headers as JS objects, etc. Right now most developers either write their own library to do these things on top of fetch or another HTTP client or use a third party library from npm. A new standard would allow us to make http reque…
Why is this being down voted? This comment seems to be making a reasonable case. In case you disagree, you may want to reply why instead of down voting.
Because fetch just landed in Node.js, making it a standard present in every context after like 5 years and he want to change the standard now.
Edit: also, you are being downvoted because the etiquette on HN are that you don't ask "why was X downvoted".
Re: Fetch API has landed into Node.js
#69Ive used Fetch in the past, great lib. I'm curious why Node core has decided to make this an official part of Node? From one perspective there could be a hard argument that this should never be a part of Node as it is an external library and not a building block of the language? Almost feels like feature creep for the core language? I know that's not the intent, but wanting to understand the logic behind this decisio…
fetch is part of the client side standard: https://fetch.spec.whatwg.org/, and had been for a while.
I don't think it is so strange for node to incorporate it as part of their standard lib as well.
1. https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Re: Fetch API has landed into Node.js
#70Ive used Fetch in the past, great lib. I'm curious why Node core has decided to make this an official part of Node? From one perspective there could be a hard argument that this should never be a part of Node as it is an external library and not a building block of the language? Almost feels like feature creep for the core language? I know that's not the intent, but wanting to understand the logic behind this decisio…
They're talking about JavaScript's fetch API. It's not an external library.