Live data from Hacker News

Fetch API has landed into Node.js

github.com

191–200 of 210 posts

Re: Fetch API has landed into Node.js

#191
Every Node.js dev should be thanking the Deno creators. It has forced them off of their "this is how Node does it" complacency. Most improvements I notice and care about on Node these days are all things that Deno already supports (fetch, ES modules, async std lib uses promises, etc).

The Web Platform APIs aren't perfect, but they are better, and more thoroughly thought out than Node's.

Re: Fetch API has landed into Node.js

#192

Out of curiosity, what took so long? It's a small API that has been stable for a long time? I'm probably missing something.

Same reason the WebSocket API isn't supported, Node already had lower level APIs and browser APIs moved 1:1 don't necessarily make sense. In this case it's a slightly extended/non-standard Fetch and enough of the "it doesn't need to be in core it can be a normal library" folks thought it'd be useful enough. And someone went through the work of actually making the native implementation.

Re: Fetch API has landed into Node.js

#194
post #71

Ive 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?

As a person who only occasionally writes JS and has zero interest in keeping track of the differences between client-side and server-side JS - fetch has been a big friction point for me in the past, it's big news to me.

Re: Fetch API has landed into Node.js

#197

Out of curiosity, what took so long? It's a small API that has been stable for a long time? I'm probably missing something.

Same reason the WebSocket API isn't supported, Node already had lower level APIs and browser APIs moved 1:1 don't necessarily make sense. In this case it's a slightly extended/non-standard Fetch and enough of the "it doesn't need to be in core it can be a normal library" folks thought it'd be useful enough. And someone went through the work of actually making the native implementation.

I actually think both the Websocket API and fetch make sense. There's nothing more frustrating than adding a bunch of checks to a SvelteKit project to see if you're on the server or not.

Re: Fetch API has landed into Node.js

#198

Earlier quoted context omitted.

Same reason the WebSocket API isn't supported, Node already had lower level APIs and browser APIs moved 1:1 don't necessarily make sense. In this case it's a slightly extended/non-standard Fetch and enough of the "it doesn't need to be in core it can be a normal library" folks thought it'd be useful enough. And someone went through the work of actually making the native implementation.

I actually think both the Websocket API and fetch make sense. There's nothing more frustrating than adding a bunch of checks to a SvelteKit project to see if you're on the server or not.

I wouldn't be surprised if WebSocket made it into core eventually tbh, the above are just examples of why such things haven't immediately. If WebSocket does it'll probably have more modifications/deviations than say Fetch did here though as well as an entire server side half. `ws` is well loved but there are 2 optional native binary addons which greatly increase performance, that alone makes a good enough case for it to end up in core - just a matter of someone finding it interesting enough to make a solid PR to do so instead of just using the `ws` library as is.

Re: Fetch API has landed into Node.js

#199
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…

> Does anyone who knows enough JavaScript point me in the right direction about it. I find all this very confusing. There isn't a straight forward solution, but the closest for me is the combination of using a transpiler (Babel), and a bundler (Webpack). A common criticism on node/javascript projects is the boiler plate setup required. As far as I know, there isn't an IDE that takes care of doing this part for you, w…

  there isn't an IDE that takes care of doing this part for you
Did you try WebStorm? Any setup specifics that it doesn't support for you?

Re: Fetch API has landed into Node.js

#200

Every Node.js dev should be thanking the Deno creators. It has forced them off of their "this is how Node does it" complacency. Most improvements I notice and care about on Node these days are all things that Deno already supports (fetch, ES modules, async std lib uses promises, etc). The Web Platform APIs aren't perfect, but they are better, and more thoroughly thought out than Node's.

What is "this is how Node does it" complacency you speak of?

Node has been talking about Fetch since at least 2018 _before_ Ryan even announced Deno. This is true for promises, ESModules etc. Ryan _attended those meetings_ in the Node collaborator summit.

Don't get me wrong I am thankful for Deno (and a contributor!) but:

- It's a lot easier to make changes when the project is new and you don't have a lot of users (which is great for Deno) whereas Node has a whole (huge) ecosystem to consider on every change. - It's a lot easier to make changes with venture capital and funding to hire a bunch of people to work on it full time vs. a project with a "regular" MIT license where the code is owned by the community and not a company.

Those are not complaints about Deno, I like Deno (and not just Ryan, Lucas, Kit, Ben and the other people are nice and helpful and the project is really nice).

It's just to explain very little of Node's innovation is (at the moment) driven by Deno.

Post reply on HN