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

21–30 of 210 posts

Re: Fetch API has landed into Node.js

#21

Post by inglor »

nefitty wrote: post #14
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.

Hey this one change is going to positively impact my day to day life. Just wanted to let you know. Thanks for sharing your hard work and time.

I'm happy to hear that but I had a very small part in it all!

The person who took it through the finish line (and deserves the most props here IMO) is Michael https://github.com/targos

The people who worked most on Undici are Matteo https://github.com/mcollina and Robert https://github.com/ronag

The person to work most on fetch in Undici is Ethan https://github.com/Ethan-Arrowood

Also worth calling our James whose work on web streams in Node as well as events/cancellation helped drive a bunch of this.

I can name maybe 50 people who worked on this effort overall at some capacity (I am one of them - spending maybe 40 years on APIs to help enable this).

Note the job isn't entirely done and help is very much appreciated!

Re: Fetch API has landed into Node.js

#22

Post by kodemager »

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 needs to be setup with require when you target an azure function and commonjs. I mean, maaaybe you could avoid it by using mjs, which is currently sort of needed to move into the node16 functionality in azure functions, even though they sort of run node16 just fine in part of them without it, and you sort of don’t want to use mjs files and so on.

I’m sure it’ll get there in a few years, but it is no doubt annoying to have to fight the toolset ever so often. Over something that feels like it should just be working.

That last part isn’t really exclusive to node these days though, is it?

Re: Fetch API has landed into Node.js

#23

Post by arcatek »

inglor wrote: post #11
kichimi wrote: post #10

Earlier quoted context omitted.

I do have a question that's only tangibly related to fetch, I was wondering what Nodes stance is on the seemingly increasing gap between the NodeJS and browser implementations of the JavaScript engine. It's still very common to see Node modules that use require(), for example, but would otherwise work flawlessly in a browser where there is no require() support (without using shims and other libraries).

I don't speak for the project a whole :) Node has supported ESModules (`import`) for a while and you can use it (either by naming your files `.mjs` or setting `type: module` in your package.json. There is a solid interop story between require/import and you can mix if you want. `require` is going to be supported "forever" so code doesn't break and both module systems work. As for the general question: Node is committ…

However note that ESM in Node comes with drawbacks that prevent end-users from relying them in various situations. Those will be mostly solved once loaders become stable, but until then it's still advised to ship packages as both CJS and ESM.

Re: Fetch API has landed into Node.js

#24

Post by inglor »

mcraiha wrote: post #15

Why it took so long? e.g. Deno had fetch support for ages

Basically because fetch isn't a great API for servers it took a while to get consensus on actually landing it for the interoprability/simple API value.

Then it took a while to get consensus it's fine to do even if we can't implement the standard fully and diverge from it on stuff like CORS (like Deno does).

Then there were a bunch of work adding APIs like `EventTarget` and `AbortSignal` to Node.js which are quirky'ish web APIs.

As a side note just to show positive collaboration: that work made me make maybe 10 PRs fixing things in EventTarget in Deno - and Deno helped Node a bunch now when landing fetch.

Then web streams and blobs and a few other things as well as the undici work in the background.

Then undici-fetch by Ethan, merge into Undici and then the PR by Michael - and it's still not done :)

Finally

Re: Fetch API has landed into Node.js

#25

Post by staticelf »

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.

Quick question, judging from the commit alone this seems like a rather small change. I assume there's more to it though. I just wonder how come features like this that kind of seems obvious to include in the ecosystem takes quite some time to land? I understand the reality is more complex perhaps, so I am genuinely curious.

I hope you realize no disrespect, this will greatly improve the daily work for me since I use node at work every day.

Re: Fetch API has landed into Node.js

#26

Post by cphoover »

mcraiha wrote: post #15

Why it took so long? e.g. Deno had fetch support for ages

Fetch evolved after promises had been standarized as the way of doing async, whereas node is older than that. Node originally used callback style for its core API and had another method for making http requests. Since fetch, developed in the browser, OS contributors have filled the void of a promise supporting http requesr library, with packages like axios, and isomorphic-fetch. Only now that the standards have finalized and we have reached consistent browser support has core team has made it a priority to include it in core.

Re: Fetch API has landed into Node.js

#27

Post by dpweb »

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…

I been naming the files with .mjs file extension which allows import keyword and top level await. No special flags needed in the latest version. I use JS not TS.

Re: Fetch API has landed into Node.js

#28

Post by rattray »

arcatek wrote: post #23
inglor wrote: post #11

Earlier quoted context omitted.

I don't speak for the project a whole :) Node has supported ESModules (`import`) for a while and you can use it (either by naming your files `.mjs` or setting `type: module` in your package.json. There is a solid interop story between require/import and you can mix if you want. `require` is going to be supported "forever" so code doesn't break and both module systems work. As for the general question: Node is committ…

However note that ESM in Node comes with drawbacks that prevent end-users from relying them in various situations. Those will be mostly solved once loaders become stable, but until then it's still advised to ship packages as both CJS and ESM.

How do you do both?

Re: Fetch API has landed into Node.js

#29

Post by jeswin »

kichimi wrote: post #10
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 do have a question that's only tangibly related to fetch, I was wondering what Nodes stance is on the seemingly increasing gap between the NodeJS and browser implementations of the JavaScript engine. It's still very common to see Node modules that use require(), for example, but would otherwise work flawlessly in a browser where there is no require() support (without using shims and other libraries).

> I was wondering what Nodes stance is on the seemingly increasing gap between the NodeJS and browser implementations of the JavaScript engine. It's still very common to see Node modules that use require()...

"Seemingly increasing gap" - how did you come to that conclusion? If anything the gap has reduced since the availability of ES modules. I see more and more libraries preferring ES modules, but ultimately that's up to the library developers.

Post reply on HN