The Web Platform APIs aren't perfect, but they are better, and more thoroughly thought out than Node's.
Fetch API has landed into Node.js
191–200 of 210 posts
Re: Fetch API has landed into Node.js
#192Out of curiosity, what took so long? It's a small API that has been stable for a long time? I'm probably missing something.
Re: Fetch API has landed into Node.js
#193Re: Fetch API has landed into Node.js
#194Ive 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?
Re: Fetch API has landed into Node.js
#195Re: Fetch API has landed into Node.js
#196Re: Fetch API has landed into Node.js
#197Out 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
#198Earlier 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.
Re: Fetch API has landed into Node.js
#199My 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
#200Every 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.
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.