Why it took so long? e.g. Deno had fetch support for ages
Because Node is legacy and Ryan Dahl moved on to Deno... Node is just an outdated 'standard' at this point.
Fetch API has landed into Node.js
101–110 of 210 posts
Re: Fetch API has landed into Node.js
#102My 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'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?
If I remember my history correctly, it's because when Node first came out, there was no import system in JS, let alone a standardized one; there was no sense of scoping (everything global), nothing about dynamic or lazy loading of dependencies, no tree shaking / removing unused code, and even going to the definition of something in an editor was difficult.
NodeJS adopted CommonJS (I don't recall if they invented it), which is a module and dependency system based on require() and exports. It was only a few years later when the JS standards body settled on import; by then, the JS (dependency / module management) world was already very divided.
Re: Fetch API has landed into Node.js
#103Earlier quoted context omitted.
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.
Oh right, because they don’t want cross-site scripts to be able to see redirected URLs since they could contain secrets. I wish we could completely do away with cross-site scripts and just have nice things!
Re: Fetch API has landed into Node.js
#104My 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…
"supported" is somewhat of a misnomer IMHO. It's only supported if the other tools you're using support ESM. Otherwise, it's not. And it's really annoying when libraries choose to go full ESM because it breaks things like tests and deployments in weird ways.
It's a pain in the ass.
Re: Fetch API has landed into Node.js
#105Hey, 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.
Where can I find an explanation about what is Fetch and why it should be in Node.js?
Fetch is a popular browser api to download and request stuff from the internet. Having the same api both in browser and in node allows easier re-use of the same application code or libraries on frontend and backend.
Re: Fetch API has landed into Node.js
#106Ive 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…
I second this, since fetch is a wrapper around xhr (though doesn’t have to be because node is a non-restricted runtime), and it diverged already for redirect semantics. It’s news, but is it big?
> It’s news, but is it big?
As someone who has been working almost exclusively on Node.js applications for years now, this is big.
Front-end developers have, for years, enjoyed this wrapper around the clunky XHR API. It is simple, intuitive, and it comes _free_ in the browser environment (and was easily shimmable before it was standard). Additionally, the depreciation of the popular request[0] a while ago, there has been a gap in The Right Way to do http requests without going into the low-level API that ‘http(s)’ provides. Fetch is promised-based (enabling seamless async/await) and, most importantly, standardized.
Basically, fetch provides a meaningful abstraction atop each platforms’ implementation of http-request-doing further unifying server-side and client-side patterns and idioms.
Re: Fetch API has landed into Node.js
#107Re: Fetch API has landed into Node.js
#108Earlier 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…
It would be useful for trusted browser extensions too, as well as probably Electon apps as well.
I don’t know if chrome apps are still in existence, but if they are the “server side” fetch spec could apply to them too.
Re: Fetch API has landed into Node.js
#109My 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 know this comment is not very helpful, but the lack of a module-system and the lack of threading are unfortunately the biggest issues that JavaScript had from the start.
Re: Fetch API has landed into Node.js
#110Earlier quoted context omitted.
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?
Usually you setup a transpiler to target both. For example, my packages are bundled with rollup towards both cjs & esm:
https://github.com/arcanis/clipanion/blob/master/rollup.conf...