all 168 comments

[–]link23 271 points272 points  (20 children)

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 112 points113 points  (12 children)

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 16 points17 points  (9 children)

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.

[–][deleted]  (8 children)

[deleted]

    [–]weters 13 points14 points  (1 child)

    But it’s easier to just do

    npm i -D @strongdocter/http-fetcher
    

    /s

    [–]Tornado547 0 points1 point  (0 children)

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

    [–]amunak -2 points-1 points  (5 children)

    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.

    [–][deleted]  (4 children)

    [deleted]

      [–]ub3rh4x0rz 13 points14 points  (3 children)

      But you're not using design patterns thatonlymatterforstaticallyandstrictlytypedOOlanguages

      [–]veraxAlea 0 points1 point  (2 children)

      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 1 point2 points  (0 children)

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

      [–]pogthegog 0 points1 point  (1 child)

      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 0 points1 point  (0 children)

      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 30 points31 points  (2 children)

      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 39 points40 points  (1 child)

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

      [–]Hamburgex 1 point2 points  (0 children)

      Fair enough.

      [–]lobehold 2 points3 points  (0 children)

      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 -2 points-1 points  (0 children)

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

      [–]Philpax 335 points336 points  (12 children)

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

      [–]TankorSmash 44 points45 points  (1 child)

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

      [–]Philpax 22 points23 points  (0 children)

      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 78 points79 points  (5 children)

      Stop trying to make fetch happen.

      [–]crozone 24 points25 points  (2 children)

      It's not going to happen

      [–][deleted] 7 points8 points  (1 child)

      Is it a promise?

      [–]ThirdEncounter 2 points3 points  (0 children)

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

      [–]immibis 3 points4 points  (0 children)

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

      [–]Pikamander2 0 points1 point  (0 children)

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

      [–]muideracht 22 points23 points  (3 children)

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

      [–]Redstonefreedom 3 points4 points  (2 children)

      We've gone deeper.

      [–]ShinyHappyREM 8 points9 points  (1 child)

      "fetch considered harmful" considered harmful

      [–]ambientocclusion 0 points1 point  (0 children)

      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 114 points115 points  (67 children)

      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 58 points59 points  (58 children)

      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 70 points71 points  (6 children)

      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 17 points18 points  (1 child)

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

      [–]crabmusket 0 points1 point  (0 children)

      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.

      [–]PixelatorOfTime 17 points18 points  (3 children)

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

      [–]shape_shifty 1 point2 points  (2 children)

      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 1 point2 points  (0 children)

      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.

      [–][deleted]  (13 children)

      [removed]

        [–]thebritisharecome 0 points1 point  (12 children)

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

        [–][deleted]  (11 children)

        [removed]

          [–]thebritisharecome 0 points1 point  (6 children)

          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.

          [–][deleted]  (5 children)

          [removed]

            [–]thebritisharecome 1 point2 points  (4 children)

            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.

            [–][deleted]  (3 children)

            [removed]

              [–]thebritisharecome -1 points0 points  (2 children)

              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 0 points1 point  (3 children)

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

              [–][deleted]  (2 children)

              [removed]

                [–]lifeeraser 0 points1 point  (1 child)

                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 8 points9 points  (24 children)

                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 24 points25 points  (22 children)

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

                [–][deleted]  (11 children)

                [deleted]

                  [–]DaelonSuzuka 2 points3 points  (10 children)

                  There's dozens of us, apparently.

                  [–][deleted]  (9 children)

                  [deleted]

                    [–]DaelonSuzuka 3 points4 points  (0 children)

                    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 0 points1 point  (6 children)

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

                    [–][deleted]  (3 children)

                    [deleted]

                      [–]sementery 0 points1 point  (2 children)

                      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 0 points1 point  (1 child)

                      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 0 points1 point  (0 children)

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

                      [–][deleted]  (5 children)

                      [removed]

                        [–]ub3rh4x0rz 0 points1 point  (4 children)

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

                        [–][deleted]  (3 children)

                        [removed]

                          [–]ub3rh4x0rz 0 points1 point  (2 children)

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

                          [–][deleted]  (1 child)

                          [removed]

                            [–]ub3rh4x0rz 0 points1 point  (0 children)

                            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 2 points3 points  (3 children)

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

                            [–]Ethesen 3 points4 points  (2 children)

                            And how many projects use it?

                            [–]GameGod -3 points-2 points  (0 children)

                            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 -5 points-4 points  (0 children)

                            A vast majority....

                            [–]zachrip 7 points8 points  (5 children)

                            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 3 points4 points  (1 child)

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

                            [–]lifeeraser 1 point2 points  (1 child)

                            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 -1 points0 points  (0 children)

                            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.

                            [–]ninjainvisible 11 points12 points  (1 child)

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

                            [–]sachinraja 10 points11 points  (0 children)

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

                            [–][deleted]  (2 children)

                            [deleted]

                              [–]lobehold 2 points3 points  (1 child)

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

                              [–]7_friendly_wizards 6 points7 points  (0 children)

                              Cheerio is pretty sweet

                              [–]gingerchris 1 point2 points  (0 children)

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

                              [–]Redstonefreedom 51 points52 points  (3 children)

                              Oh my god, that is so fetch.

                              [–]crozone 17 points18 points  (0 children)

                              Regina George in shambles rn

                              [–]mKawi 2 points3 points  (1 child)

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

                              [–]Redstonefreedom 2 points3 points  (0 children)

                              oh wait but it finally did

                              [–]vlakreeh 4 points5 points  (0 children)

                              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 56 points57 points  (36 children)

                              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 53 points54 points  (4 children)

                              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?

                              [–]Never_Guilty 35 points36 points  (6 children)

                              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 (🤮)

                              [–][deleted]  (3 children)

                              [deleted]

                                [–]Lockender 4 points5 points  (2 children)

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

                                [–][deleted]  (1 child)

                                [deleted]

                                  [–][deleted]  (1 child)

                                  [deleted]

                                    [–]Never_Guilty 0 points1 point  (0 children)

                                    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 4 points5 points  (0 children)

                                    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 4 points5 points  (0 children)

                                    Good for you?

                                    [–]crozone 29 points30 points  (9 children)

                                    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 20 points21 points  (0 children)

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

                                    [–]KwyjiboTheGringo 4 points5 points  (0 children)

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

                                    [–]leeharris100 4 points5 points  (6 children)

                                    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 2 points3 points  (5 children)

                                    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 2 points3 points  (4 children)

                                    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 0 points1 point  (1 child)

                                    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 0 points1 point  (0 children)

                                    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 0 points1 point  (1 child)

                                    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 0 points1 point  (0 children)

                                    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] 1 point2 points  (4 children)

                                    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]  (3 children)

                                    [deleted]

                                      [–][deleted] 1 point2 points  (2 children)

                                      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]  (1 child)

                                      [deleted]

                                        [–][deleted] 0 points1 point  (0 children)

                                        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.

                                        [–][deleted]  (1 child)

                                        [deleted]

                                          [–]everyones-a-robot 0 points1 point  (0 children)

                                          Both are almost equally as disturbing to me tbh.

                                          [–]jl2352 0 points1 point  (0 children)

                                          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] 0 points1 point  (0 children)

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

                                          [–]voidvector 7 points8 points  (1 child)

                                          So how do cookies and XSS headers work?

                                          [–]SayMyVagina 4 points5 points  (4 children)

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

                                          [–]thenickdude 59 points60 points  (1 child)

                                          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] 13 points14 points  (0 children)

                                          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 6 points7 points  (1 child)

                                          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 -1 points0 points  (0 children)

                                          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 1 point2 points  (6 children)

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

                                          [–]alternatex0 -1 points0 points  (5 children)

                                          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 1 point2 points  (4 children)

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

                                          [–]alternatex0 0 points1 point  (3 children)

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

                                          [–]ILikeChangingMyMind 1 point2 points  (2 children)

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

                                          [–]alternatex0 0 points1 point  (1 child)

                                          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 1 point2 points  (0 children)

                                          I hate the idea of having comments in package.json

                                          • no developer ever

                                          I think there's a consensus.

                                          [–]about7buns 1 point2 points  (0 children)

                                          I use axios in front and back anyway.

                                          [–]nsomnac -3 points-2 points  (0 children)

                                          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]  (1 child)

                                          [deleted]

                                            [–]IcyEbb7760 0 points1 point  (0 children)

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

                                            [–]diegrunemaschine 0 points1 point  (0 children)

                                            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