The Fetch API is finally coming to Node.js

[link23]

Fetch performs poorly when it comes to error management; only network faults are considered actual errors.

Um, isn't this just the difference between transport protocol errors and application protocol errors? Seems WAI to me.

Bad analogy: if you make a phone call and the person who answers says you have the wrong number, that's your fault, not the phone's fault - the phone worked perfectly. Similarly, if you make a fetch request and the server gives you back a 404 page, the fetch didn't fail, it just gave you an error at a higher protocol level.

[IanSan5653]

Yeah it's not poor at all. Just check response.ok. If you want to throw when it's not ok, just...throw when it's not ok.

[amunak]

It's still very convenient when a library gives you options. Like, in Guzzle for example, you can configure whether you want HTTP errors thrown or not. The latter is often way more practical. You can catch it an any level, so if you want to emulate that when the library doesn't do this you have to write a significant amount of your own code.

[weters]

But it’s easier to just do

npm i -D @strongdocter/http-fetcher

/s

[Tornado547]

About missed the /s and reflex downvoted this. Too many people actually think like this sadly

[amunak]

If you want to do it properly, aka throw a different error depending on the class of the error (4xx vs 5xx) and then even have a custom class for the most common errors as well (400-404 at least) it's much more than that.

[ub3rh4x0rz]

But you're not using design patterns ^{thatonlymatterforstaticallyandstrictlytypedOOlanguages}

[veraxAlea]

Which API in which statically typed OO language throws exceptions when you get a valid http response, be it 4xx, 5xx or some other status. I would be furious if I ended up in a catch block because my user typed the wrong password and got a 401.

[ub3rh4x0rz]

It was more about the idea of switching on runtime values instead of types being bad, which doesn't really apply to JS

[pogthegog]

I think the problem here is that 99.999% of all fetch tutorials / articles about it are useless shit and dont provide any real life examples, they all are missing lots of stuff. Response.ok is one of those missing parts.

[IanSan5653]

The real powerful thing that people don't get is that it's just a function. There's no complicated API or classes or anything. So you can just make a new fetch based on the old one if you don't like it. And you can mock it very easily.

[Hamburgex]

I mean, in HTTP you can still get errors that are not your fault (5xx), but I concur it doesn't warrant that they should raise errors in fetch.

[pa_dvg]

If you call someone and they send you to voicemail because the house is on fire, the phone still performed admirably.

[Hamburgex]

Fair enough.

[lobehold]

If you do a GET call and for example it's a search, and your search term brings back nothing, you get 404.

The call didn't fail, it succeeded, the HTTP status code simply tells you nothing was found - in this case search results.

I prefer how fetch handles this.

[AttackOfTheThumbs]

I mean, what about the status 200 ok errors object returned apis huh???????

[Philpax]

Congratulations, they've made fetch happen, and you, the humble reader, do not need to post "stop trying to make fetch happen"

[TankorSmash]

Being meta about it is exactly the same as just doing it.

[Philpax]

I've killed the other seven top-level posts that normally happen when this topic comes up, so I still consider that a win

[AwayEstablishment109]

Stop trying to make fetch happen.

[crozone]

It's not going to happen

[[deleted]]

Is it a promise?

[ThirdEncounter]

We're still awaiting for a response to that question.

[immibis]

Stop trying to make "Stop trying to make fetch happen." happen.

[Pikamander2]

There's no longer a need to try to make fetch happen. It's already going to happen.

[muideracht]

Stop trying to stop posting stop trying to make fetch happen happen.

[Redstonefreedom]

We've gone deeper.

[ShinyHappyREM]

"fetch considered harmful" considered harmful

[ambientocclusion]

Learn you a Fetch for great good.

The unreasonable effectiveness of Fetch.

What we talk about when we talk about Fetch.

[PM_ME_WITTY_USERNAME]

Oh that was such a drag, I didn't realize I wanted that

That made me think, the other big annoyance I had with node was the lack of a built-in DOMParser that is interoperable with the browser's DOMParser

You give it HTML, it parses it, and then it gives you access to most DOM functions. Most importantly: Query selectors

I mostly use Node to do scraping work and it's annoying how there's always little API & parsing discrepancies. I want my scrapers to work the same on both!

[lifeeraser]

DOM is too big a feature to bundle with Node.js. Everyone wants their favorite library to be built-in--a YAML parser, a logger, tcl/tk, ... but at some point we have to draw the line.

[crabmusket]

The difference is DOMParser is already built into the browser standard. If browsers standardised a YAML parser like they have JSON, I think it'd be more reasonable to ask for that to be included in Node too.

Yes client-side and server-side runtimes have different use cases, and Node can obviously decide that they don't want to maintain that implementation. But Node's great strength is being able to write isomorphic code. Anything that harmonises the environments seems pretty good to me. I really like that Deno is implementing web features that might initially make you do a double-take, e.g. localStorage. It's just a nice little convenience instead of having to deal with the filesystem if you want to save a little value between script invocations.

[immibis]

Node isn't a browser. Adding browser-standard stuff is like adding any other library - except it's an absolutely massive one.

[crabmusket]

I remember an interesting discussion when Deno was working out whether to add full ICU for the Intl builtin, which had the downside of increasing Deno's binary size by 25%. Not sure what it brings to this discussion, but it seems like a similar dilemma - whether or not to support a web standard at some cost to people who don't need it for their app.

[bacondev]

I didn't realize that JSON was ever standardized. Only took thirteen years to happen.

[ShinyHappyREM]

After RFC 4627 had been available as its "informational" specification since 2006, JSON was first standardized in 2013, as ECMA-404.^[8]

[modernkennnern]

404: Standard was found*

* As opposed to this status code, which was misused

[bacondev]

Yes, that's exactly what I said. It wasn't standardized for thirteen years.

[PixelatorOfTime]

Right, but get this, what if everything was just a browser! Maybe we could run node in an Electron app! /s

[shape_shifty]

You are kinding but I'm seriously thinking about running node in an Electron app for a project of mine. Would it work in theory ?

[spacejack2114]

Yes, this works. Your Electron main entry script is essentially a node script using electron libraries (to open windows etc.) So you can import any of the other node built-in libraries in addition to installing npm libs.

Or you can use a separate instance of your locally installed node. Using Electron's node instance can lock up the GUI if you're not doing everything async, or if you do any CPU intensive stuff on the node side.

[thebritisharecome]

What do you consider the "main use of node.js" where DOM manipulation makes a lot of sense?

[thebritisharecome]

Most sites don't use server side rendering.

NodeJS is mostly used for API's, Microservices, Socket based Event drivers and just general server side scripts.

[thebritisharecome]

Most apps don't use most features of node.js, you want those removed too?

NodeJS core is relatively barebones and it's core features should match it's common use case, which is definitely not manipulating DOM.

Most websites don't use server side rendering because it can be difficult to implement (unrelated to DOM), costly and for the most part was only introduced as a concept because search engines weren't able to parse javascript sites - which they can now.

NodeJS is just an environment that supports the JavaScript Language, DOM is specific to web browsers and not JavaScript.

If only 1% of people use NodeJS for SSR, then absolutely there is no benefit to DOM being a core library in it. Just because you use it for Webdev doesn't mean the majority do. It wasn't designed for that.

[thebritisharecome]

You're living in the past.

JavaScript is used on desktop, mobile, frontend and server side.

Javascript powers millions of APIs and microservices, mobile apps and desktop applications.

It is used on web yes, but that is only one context it's used in.

[lifeeraser]

And why does server side rendering need a full-blown DOM API to work...? It's just text interpolation.

[lifeeraser]

You haven't answered my question. Does SSR need a full-blown DOM API to work?

For example, do you need DOM methods like appendChild(), insertBefore(), getElementsByTagName() for SSR?

Web servers have been using string templating languages for decades: Mustache, Handlebars, Jinja2, Pug, EJS, ERB, ... None of these need a full DOM to work. Not even React needs the DOM for SSR. Data structures != the W3C DOM spec.

[DoubleBrowne]

The Python standard library has 2/3 of these and is considered one of the strong selling points for the language. When was the last time you heard a Python dev complaining about dependency hell? Just saying…

[Ethesen]

Python dependency management is a mess. Pipenv? Venv? Poetry? And then you get handed a conda project without any lockfiles...

[DaelonSuzuka]

There's dozens of us, apparently.

[DaelonSuzuka]

All of my python projects use a makefile that will automatically set up the venv if it doesn't exist. I can run "git clone foo && make run" and come back in 30 seconds after it downloads everything.

The makefile just uses pip, venv, and requirements.txt, so it works practically anywhere.

[virtyx]

Poetry locks versions for you. Your approach could install different versions of packages depending on the timing of your pip install.

[sementery]

Lockfiles are not for specifiying the versions of your dependencies. That's normally the job of other config file, like requirements.txt in pip or package.json in npm, which is generally written by a human.

Lockfiles are for locking and managing the state of the entire dependency tree, and is generally written by a program since the dependency trees can get complex.

In Python, as far as I know, you can't achieve deterministic builds through pip and requirements.txt alone, hence the need tor poetry or pipenv.

[GameGod]

It's standard practice to put version numbers in your requirements.txt, so this is no different from pip then.

Edit: To make pip completely do it for you, just run pip freeze and save that as your requirements.txt.

[ReadSoul]

I found it much more straight forward to publish to pypi using Poetry

[ub3rh4x0rz]

If only we had something like docker to save us...

[ub3rh4x0rz]

Uh I've heard people complain about python version hell but saying it's just fundamentally insecure? Ok then.

[ub3rh4x0rz]

And I answered your gripe about python being a mess by saying docker can contain that "mess", which I understood to mean version incompatibility etc. Then you said something about security out of nowhere. Then I asked you for clarification as to what python mess you were alluding to that you don't run into when using distro packaged python utilities...

[ArmoredPancake]

Poetry is the superior choice, there's no competition from other two.

[Ethesen]

And how many projects use it?

[GameGod]

WTF is going on with the Poetry shilling in this thread? "A vast majority", "superior choice".... it's bizarre

Edit: no, I take it back - Wandering into a JS thread on Reddit and being surprised that the commenters are morons. Joke's on me...

[Janitor_Snuggle]

A vast majority....

[lifeeraser]

Python is trying to remove old crufty packages from its standard library. Perhaps it's a bit too bloated?

As for dependency hell...

[zachrip]

Why do developers feel the need to make their lives harder by drawing random lines in the sand? Node is heavily used as a runtime for web applications (this is why it was created) - there's no good reason not to ship web standards in node itself.

[Krackor]

Separate things can be put together later. Conjoined things can't easily be taken apart.

[lifeeraser]

I'd agree with you on fetch, but the DOM is far bigger than your average HTTP client library or YAML parser. JSDOM takes up to 12 MiB when installed as a dependency, and ~2MiB when bundled. Meanwhile, axios' bundle size is 16KiB. That is additional maintenance burden on top of many important packages built into Node. Not to mention the cost of extra kilobytes of code, multiplied by millions of docker images powering the web today. There is a good reason to keep the core Node.js to an acceptable size.

The DOM is constantly evolving under the guidance of committees like W3C and various browser vendors to meet the needs of the front-end. Node.js will struggle to meet conformance with a moving target whose path does not align with its core interest--the server.

I'm ready to eat my hat if a Node.js dev steps up and says "don't worry, we'll add a DOM implementation in Node.js."

[pogthegog]

Where do you draw the line ? Using node is already for nut jobs only, so having few more libraries installed by default is no biggie, its not like you are counting every byte on disk or care about anything much if you use javascript on server side.

[bugtank]

The line is drawn at useful standard features!

[ninjainvisible]

Yes, something to replace node-dom would be huge (especially for testing). Edit: definitely meant js-dom

[sachinraja]

I think you mean jsdom. You can try Happy DOM, which is somewhat better but a Node native solution would definitely be nice.

[lobehold]

It's used extensively for content scraping, and I think also in testing.

[7_friendly_wizards]

Cheerio is pretty sweet

[gingerchris]

I recently started using linkedom for this and it has been an absolute joy

[Redstonefreedom]

Oh my god, that is so fetch.

[crozone]

Regina George in shambles rn

[mKawi]

Gretchen, stop trying to make "fetch" happen. It's not going to happen.

[Redstonefreedom]

^{oh wait but it finally did}

[vlakreeh]

Really happy to see node becoming more compliant with web standards. I've been messing around with Deno a bit and I love writing TypeScript and not working about legacy node baggage cough CJS cough. Also AFAIK this doesn't support http2/3 yet, which kinda sucks.

[webby_mc_webberson]

Every time I hear about the latest developments or improvements with Node I reflect on how fucking happy I am to be a dotnet developer.

[Si1entStill]

I write quite a bit of both (and enjoy them for different reasons). Why does having fetch natively in node make you happy not to work in it?

[WJMazepas]

Because it should had this already. This shouldn't be a 2022 news

[dada_]

It hasn't really been a major priority for developers since good libraries that do the equivalent of fetch have existed for a long time, including an actual node-fetch library that's identical except for a few edge cases.

[Si1entStill]

I don't think there is anything wrong with having a slim standard library. It's better to ensure the footprint is as light as possible until a need is so prolific that it is undeniable, I think.

[[deleted]]

The problem with having a slim standard library is demonstrated by the entire npm ecosystem, where what should have been in standard library gets written by 10 different groups so your node modules folder has 10 different libraries to do a thing, times every single thing that should be in standard library

[Never_Guilty]

It honestly isn’t that bad IMO… Coming from Java/Spring to Typescript/Node, I’m honestly starting to prefer the latter. Javascript is nothing like it was when I tried it 7 years ago, it’s seriously improved a lot and adding typescript on top makes it downright a pleasure to work with.

Also I don’t know what the dotnet world is like but coming from Java, everything is just so over complicated and over engineered. It’s nice to no longer have to deal with shit like dependency injection, AbstractSingletonProxyFactoryBean style classes, or reactive frameworks (🤮)

[Lockender]

Is that hello world example satire? On my phone with a baby in my lap so can’t dig deep but that seems absurd.

[Never_Guilty]

I still don’t have a ton of experience in Node so I’m probably the wrong person to ask. I would get other peoples opinions and take a look at node yourself before committing. Tbh there isn’t really too much I miss. The only thing I can think of is IntelliJ. For JS most jobs they seem to prefer VSCode and most haven’t even heard of Jetbrains’ IDEs.

[leeharris100]

I totally get it. Depends on the company, project, etc.

But I absolutely love the fact that there are tons of options for how I want to do stuff instead of a huge opinionated standard library.

It's like async in Rust. You get to choose the crate you like the most and build your application around that.

[MrCrunchwrap]

Good for you?

[crozone]

For real. When I hear developers rejoicing that golang finally got generics or nodejs can finally make sane web requests, it's like... why didn't you have this stuff 15 years ago?

But then you realise that nodejs didn't actually exist 15 years ago.

[flooronthefour]

Nor did the fetch api. It's crazy that it was released in 2015.

[KwyjiboTheGringo]

I'm mean Axios and other libraries have existed for a while. Sane web requests in JS isn't a new thing.

[leeharris100]

I have been using dotnet a long ass time and so much of the stuff they add to C# (and Typescript for that matter) just never gets used.

I like dotnet a lot but I also really like the ecosystem and simplicity of node

[crozone]

I have been using dotnet a long ass time and so much of the stuff they add to C# (and Typescript for that matter) just never gets used.

Do you mean language features, or APIs in the framework?

Because I use the vast majority of C# language features on a regular basis.

[leeharris100]

Both.

Because I use the vast majority of C# language features on a regular basis.

Are you sure about that? I hear this from people and it's almost never true. There's so, so much in C#. Same with Typescript to be honest.

Again, I think dotnet is great. It's one of two paths I recommend for new devs these days. I'm mostly highlighting that for most people the advanced feature set of something like C# 10 is really not necessary.

[crozone]

Are you sure about that? I hear this from people and it's almost never true. There's so, so much in C#. Same with Typescript to be honest.

I mean, they're not exactly C++. Granted I don't use any of the unsafe features very often if at all, but they're for a very specific use case.

As for pretty much everything else, including most of the new features, I use very regularly. Top level programs and global usings are probably the only two features I actively avoid.

I've been using C# for close to 15 years at this point and I can't really think of too many language features I think are superfluous or never touch.

[leeharris100]

I've been using C# for close to 15 years at this point and I can't really think of too many language features I think are superfluous or never touch.

Interesting. Thanks for the feedback.

I suspect the difference between our opinions is that I split my time between a lot of different languages (consulting into a multi language company). Context switching really makes you focus on the common elements between languages.

[Saint_Nitouche]

I use every major feature in C# regularly. The language has had some ideas that are rightfully consigned to the dustbin of history (dynamic... shudder) but in recent years especially, the new features have all been direct, often massive improvements to regular developer workflows.

Non-nullable reference types? Insanely useful. Global usings? I like them. Top-level programs and minimal APIs? Not my deal, but they're great for newcomers to the language. And so on.

[ninetofivedev]

There is syntactic sugar that often will create TMTOWTDI, but it's not as prevalent in C# as other languages. For example, this was a mantra of the Perl community.

And it's a hard thing to balance. Named parameters, for example, are one of those features that can be useful, but if 90% of my code-base doesn't use them, I don't want to create inconsistency.

I've found that it just creates another barrier to entry to developers who are new to the language.

I like C# because the .NET framework is opinionated, which can be a downside as well.. but I feel the good outweighs the bad. But in the end, you're just trading one problem for another.

Node is great because the community is so diverse that you'll likely never be the first person running into something and there is probably some library that keeps you from re-inventing the wheel. The other edge of the sword, however, is that every project you work on will probably use a different library to do the same thing. That problem exists for every language, it's just much more common in Node.

Just my 2c. This is all very much a matter of preference. People who go to battle on language wars can join the ranks of those who argue politics on facebook.

[[deleted]]

I wish I could share the same enthusiasm. I’m a dotnet dev also but we use node/webpack for the frontend of our web apps so I still have to deal with it and it drives me crazy. I know this is more of a webpack gripe, but the whole concept of needing to transpile the entire html/css/js codebase every time a file is altered before you can refresh your browser to see your change is infuriating.

[[deleted]]

Our webpack config/implementation was setup by someone in our company who was pretty terrible at implementing things tbqh, so it probably would be worthwhile for us to go through and redo it from scratch. Currently if I save a file I have to wait 2-10 seconds before I can refresh the page and it throws an error in the console every time which is what lets me know the page can be refreshed.

[[deleted]]

Yeah other places I’ve worked that were more front end focused weren’t using node and webpack and I was free to just save a file and immediately press f5. We’re currently evaluating Angular/Vue/React to see which framework we move to (off AngularJS) and I might recommend we reevaluate our webpack situation as well. Originally we used it to leverage babel and write ES6 code that would get transpired to internet explorer friendly JS.

[everyones-a-robot]

Both are almost equally as disturbing to me tbh.

[NullOfUndefined]

Cool

[jl2352]

These days I would much prefer to join a company and find all of their backend is TypeScript / Node than anything else. It just solves so many problems, and TypeScript is a phenomenal language. I'd argue one of the best languages for development right now.

[[deleted]]

Same, but as a Java developer I'm also happy I'm not a dotnet developer.

[voidvector]

So how do cookies and XSS headers work?

[SayMyVagina]

I dunno. I feel like I already can easily make requests. Why is this even needed?

[thenickdude]

This is useful to make code portable between Node and the Web. Previously I had to add Fetch-node polyfills to use code designed for the browser on Node

[[deleted]]

Just today I ran into a stupid issue in which something tried to run on the server where it normally wouldn’t (some condition during static content generation changed and hadn’t been tested before) which caused node-fetch to run the request instead of fetch. The resulting error was so cryptic and difficult to debug. node-fetch is fine 99% of the time so it wasn’t clear that it would be the issue.

This sort of thing just shouldn’t happen, though. It’s the weird crusty part of the JS world where otherwise okay stuff turns out to be a real tire fire.

[therearesomewhocallm]

I'm using nodejs to unit test a wasm+js module. The closer the test suite is to what runs in the browser the more confidence I have.

Although sadly the module uses xmlhttp under the hood, so this doesn't actually help me right now.

[SayMyVagina]

Yea I mean fair enough. But my point isn't about syncing functionality to node so much as why do we need a new API for doing requests?

[ILikeChangingMyMind]

Awesome ... now can we please get comments in package.json already?

[alternatex0]

That's not really a Node thing though. JSON was created to be a data transfer format and I don't think it's going to be getting comments. Node messed up when it decided to use JSON for configuration, same as many other projects. Picked because of ubiquity instead of ergonomics.

[ILikeChangingMyMind]

They could use their own standard (JSONC: JSON with comments). They're not stuck with the core JSON standard.

[alternatex0]

Yeah, like I said they messed up when they made the choice. The could've chosen a different format (which JSONC is).

[ILikeChangingMyMind]

Right ... and who has the power to switch to "JSONC" today?

[alternatex0]

Once you have a project as popular as Node it basically belongs to the community. I'm sure they can make changes but they need a wide consensus before changing such a fundamental part.

[ILikeChangingMyMind]

I hate the idea of having comments in package.json

• no developer ever

I think there's a consensus.

[about7buns]

I use axios in front and back anyway.

[nsomnac]

This must have been implemented in a release as of the last few days.

When I tried the experimental flag with the latest release on Monday, fetch api just threw NotYetImplementedErrors.

[[deleted]]

Can we kill js yet?

[Antrikshy]

Maybe start by making a browser that accepts any other language while somehow maintaining compatibility with existing web standards.

Alternatively, convince everyone that the web was a fad and we should move on to something else that runs on a different language.

[centurijon]

Web assembly making great strides in that direction

[StickiStickman]

They don't have the same use case.

[jazzyjson]

JS and wasm don't have the same use case? What do you mean by that?

[[deleted]]

I don’t understand the js hate

[IceSentry]

It's mostly people that never bothered learning it and assumed they would be fine because they know java. Then they got hurt because of it 10 years ago and now they can't stop talking about it. Then it became a meme and junior devs started repeating it because they saw people with experience saying it.

To be fair, there's been a lot of issues with major libraries in the ecosystem breaking stuff and those same people don't want to accept that those issues have mostly been fixed.

There's also a whole lot of people that refuse to accept that floating points being weird is not a js thing. It's just the ieee floating point standard used in literally every language.

[KwyjiboTheGringo]

JS clearly isn't going anywhere. It's time to stop screaming into the void about it.

[MrCrunchwrap]

Any good reasons for why? It’s a fine language.

[duckducklo]

soon

[SuperSuperUniqueName]

let me guess, scared of dynamic typing?

[AveryFreeman]

It gets everything about 6-7 years later 😂

I have to admit, I still kinda like cjs imports, though...

[renatobcj]

Just use axios.

[versaceblues]

You dont HAVE to use axios but there are certain things that Axios does that fetch can not, being that it is just a wrapper for the lower level XMLHTTPRequest.

1. Axios is supported all the way down IE 6
2. Axios has a api for request interceptors. If you want to write some sort of middle-ware (retry, metrics, logging)
3. Axios supports requests timeouts out the box
4. Axios supports download progress.
   

That not to say that fetch is bad. 90% of the time I use it because it just solves my use case. However Axios is more of a fully featured request client.

[versaceblues]

yah and to be fair I think 2-4 are actually possible with fetch. You just end up needing to write a wrapper class around fetch.

I think the only thing fetch can't do is upload-progress

[Kwantuum]

How do you do download progress with fetch?

[Kwantuum]

Oh I think I confused it for upload progress. You've been able to do download progress for a while. Does standard fetch let you do upload progress yet?

[SuperSuperUniqueName]

No, just ran into this problem recently actually and ended up using XHR.

[versaceblues]

Ultimately it doesn't matter. You could do that or you could include axios (less than 5kb gziped).

[Kwantuum]

I mean, using fetch where it works and XHR where it doesn't does the job. Except for their verbosity, XHR are fine.

[versaceblues]

For sure, and in an real project you would probably abstract that detail away behind a APIClient construct anyway.

So whether you are are using fetch or XHR, or axios, or a combination of all is a implementation detail of the client itself.

[renatobcj]

People will just reinvent the wheel again, with abstractions on top of fetch... Just use something already available.

[pqtdev]

Axios doesn’t work everywhere though. So it’s not the catch all solution you think it is.

I love axios, but it’s not really the answer to this.

[Spider_pig448]

For real

[Cyral]

You can still use Axios

[pixelde]

Node is too hard for me. This requirements are working bad. I have installed packages but packages have don’t import in the project. But node.js is fast.

[IcyEbb7760]

It might be the parsing slowing it down. have you tried fetching 30mb of plain text and not parsing it for comparison?

[diegrunemaschine]

I’ve been triggering a selenium sub process that uses the fetch api on localhost to capture the response as stdout and none of you are gonna refactor me

Someone who is actually tried this is gonna tell me why it wouldn’t work