Live data from Hacker News

Fetch API has landed into Node.js

github.com

181–190 of 210 posts

Re: Fetch API has landed into Node.js

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

None of the things you mentioned are reasonable default behaviours, and are easy one liners. You don't need a library for any of that.

Thanks for your opinion, however as mentioned, or as you’ll be aware if you’ve used JavaScript, these are well worn cow paths that have been default in the most popular HTTP clients for a decade now.

Re: Fetch API has landed into Node.js

#183
post #119

Earlier quoted context omitted.

As mentioned existing HTTP clients had this behaviour back in 2012, the designers of fetch chose to ignore these cowpaths in favour of a more minimal implementation requiring the use of third party HTTP clients in both browsers and node, simply to have reasonable defaults and not repeat oneself, for the foreseeable future.

the value the js community gets from `fetch` being a unified standard is far, far greater than the benefit you as a developer would get from not having to add 15 extra LOC around `fetch`, that you'll probably hide behind a `fetchJSON` function anyway.

[deleted]

Re: Fetch API has landed into Node.js

#184
post #119

Earlier quoted context omitted.

As mentioned existing HTTP clients had this behaviour back in 2012, the designers of fetch chose to ignore these cowpaths in favour of a more minimal implementation requiring the use of third party HTTP clients in both browsers and node, simply to have reasonable defaults and not repeat oneself, for the foreseeable future.

the value the js community gets from `fetch` being a unified standard is far, far greater than the benefit you as a developer would get from not having to add 15 extra LOC around `fetch`, that you'll probably hide behind a `fetchJSON` function anyway.

Point is everyone had a slightly different 150 LOC or a library to achieve essentially the same thing.

We could have stuck with ‘if index is not equal to minus one’ but we have array includes now for the same reason.

Re: Fetch API has landed into Node.js

#185

Earlier quoted context omitted.

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

This is what frustrates me so much about javascript. Everything is all over the place.

Eh, I mean I get it JS lacks a real standard library but at the same time you don't see HN fill up with people saying C is all over the place because when they went to implement an HTTP call glib doesn't mirror libuv or C++ is all over the place because POCO doesn't mirror Boost and so on.

The "all over the place"-ness tends to come more from people who act like changing to a newer library is the only way to code something new not from the lack of JS forcing a single API be used across every app regardless of type.

Re: Fetch API has landed into Node.js

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

FormData and Blob/File support?

Re: Fetch API has landed into Node.js

#188

Earlier quoted context omitted.

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

why are you writing node applications without using package.json? it sounds like you're looking to have a problem with javascript tbh. don't use it, whatever

There is absolutely no need for a package.json when using ES6 imports without a build step. Package.json doesn't do anything when I'm loading the code in a browser, why would I have to use it when I want to run the same JS code with node?

Re: Fetch API has landed into Node.js

#189
post #24
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'is…

I came here to ask the same question. Thanks for this thoughtful comment and congrats!

Re: Fetch API has landed into Node.js

#190
post #90

Earlier quoted context omitted.

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 (p…

> Some people tried to force ESM adoption by making popular modules ESM-only for no technical reason Being the standard for the lsat 7 years strikes me as a good reason.

Going X-only for a political reason is not a good one, especially if the standard is of a different platform, which had no X at all back when the de facto standard was set.
Post reply on HN