Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fetch API has landed into Node.js

github.com

Post reply on HN
Print view View original

81–90 of 210 posts

Re: Fetch API has landed into Node.js

#81

Post by andrewl-hn »

inglor wrote: post #58
nailer wrote: post #50

Earlier 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…

A new standard would need buy-in from browsers to actually be a standard. Browsers likely don't have a lot of incentive to make spec changes only Node is interested in (like making the whole spec more complicated from their point of view because of Node's (or Deno's) different security model). The level of collaboration and good-faith we've been getting from spec bodies like WHATWG is very high as it is and we really…

Does it have to be a buy-in, though? You could agree on server-specific extensions to fetch and codify them in the same spec (so it doesn't get lost otherwise). Browser vendors wouldn't need to implement it but they will still keep an eye on it when working on future browser apis.

Re: Fetch API has landed into Node.js

#82

Post by mschuetz »

inglor wrote: post #78
mschuetz wrote: post #65

Earlier quoted context omitted.

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

Browsers will happily accept `.mjs` files they don't actually care about file extensions only about `Content-Type` and type=module on the script tag :]

Plenty of (third-party) imports specifically reference "*.js" files so no, this doesn't work.

Re: Fetch API has landed into Node.js

#84

Post by inglor »

esamatti wrote: post #83

Does this contain `request.formData()` and `FormData`? https://developer.mozilla.org/en-US/docs/Web/API/Request/for... https://developer.mozilla.org/en-US/docs/Web/API/FormData

> `request.formData()`

Yes.

> FormData

Yes, but not in that PR since `FormData` needs to behave differently as part of the platform but there is intent to support it before moving from experimental.

Re: Fetch API has landed into Node.js

#85

Post by huksley »

kodemager wrote: post #22
thyrox wrote: post #16

My 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…

Import is slowly becoming the standard, but working with typescript professionally modules has easily been the most annoying part of the Node experience. It works pretty well, and then you need to use something like Azure Functions and then suddenly it doesn’t. For various reasons. My most recent example was using lodash, which works perfectly fine with import with typescript targeting esnext in node16, but then need…

I had the same problem so for serverless functions I am using standalone webpack config which transpires functions into the supported by the cloud format

Re: Fetch API has landed into Node.js

#87

Post by gk1256 »

inglor wrote: post #4

Hey, Node core person here (and the person who triggered the land) - we're super excited for this and would love help and feedback. This is still experimental and we'd love to hear from the community what you'd like to see.

I wish if Node had a way to enforce any case in its requests.

Re: Fetch API has landed into Node.js

#88

Post by zamadatix »

krossitalk wrote: post #13

As someone browser focused this surprised me. I've been using fetch() for years now.

Not every browser API is an instant candidates to be added to Node's core. If there isn't a big performance hit from doing it as a user library or lack of functionality to do it as such in the first place then it's rare it'll be brought into core right away, if it will at all.

It's nice to see the really popular ones make it in though, makes for fewer dependencies when doing browser compatible projects and also allows one to be lazy and not learn the Node way of doing it. Maybe we'll see websocket go into core some day too.

Re: Fetch API has landed into Node.js

#89

Post by astrosi »

tshaddox wrote: post #79
zebracanevra wrote: post #45

Earlier 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…

Is this not what redirect: “manual” is in the MDN fetch docs? https://developer.mozilla.org/en-US/docs/Web/API/fetch

In that in the browser you are able to see that you have gotten a 301/302 response but can't see where the redirect would have sent you.

Re: Fetch API has landed into Node.js

#90

Post by wruza »

thyrox wrote: post #16

My 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…

In short, node has imports, browsers have imports, but node-related toolkits do not support it, and people still webpack bundles because development and deployment processes are a thing, and it doesn’t matter much which module system a “binary” bundle uses in the end.

Some people tried to force ESM adoption by making popular modules ESM-only for no technical reason, but tools are not there yet, and it only annoyed (predictably) half of the internet. Because even if you are pro-ESM or indifferent to it, you can’t do much to migrate your projects’ build pipelines. If you see typescript and webpack, you wouldn’t see “ESM” in there. It either doesn’t work or is too fragile for production.

People who claim it’s done say so because they are using particularly unaffected stacks (including no stack). Idk which way to promote ESM would be the most correct, but this one is too deceptive.

Post reply on HN