It was always about first mover advantage and never about building a sustaining car manufacturer. It was about moving an industry.

Train a generation to min/max stats and then put them in a time box limit and then explain to them why “this is normal”.

The issue is, and always will be, competing views on what these services are for. Most, see them as augments of their normal everyday workflow. Others see it as the tool that allows their creativity to flow as fast as their thoughts do. The problem is the service is more than capable of catering to both but the creative vibe commander will hit those limits far faster. Simply telling them to “take a break” is a kin to those video game screen nags that developers were forced to put into games to remind people to pee.

Welcome to the Authoritarian States of Sycophancy. Or ASS. As we are referred to around the world.

Ummmm… I fly drones at 8,000ft for arial mountain shots… drones are surprisingly capable given good wind conditions.

That would be against the law in the US. https://www.faa.gov/uas/recreational_flyers

Only if you’re caught. It’s perfectly fine to put your body and life on the line and go paragliding at those altitudes but the moment you strap a headset on for FPV, it’s “illegal”.

Not if you stay within 400 feet AGL of the mountain terrain. You can be over 400 feet MSL (mean-sea-level) but still be within 400 feet above-ground-level from where the drone's sitting in the sky.

If I'm still following the plot, this means protesters just need to get their mountains to follow ICE activity (but remain 3000 feet away, laterally) for lawful recording.

Drone altitude restrictions are AGL, not ASL.

I go out on top of the highest local mountain and send a drone up to 12,300' and the FAA won't care. I do the same thing over my house, they would very rightly be quite upset. (But I think it's BLM would care about the drone over the mountain--it's wilderness terrain, no powered vehicles of any type except for emergency use.)

This is also why LLMs get 80% of the way there and crap out on logic. They were trained on all the open source abandonware on GitHub.

Government budgets man…

"You feel a certain force" is that true in zero-g?

Yes

Well, technically no. Zero g, as in zero gravity, is force less. We don’t have a region of space we know of that can block gravity.

To protect the normies from harmful malware… not on their approved vendor list.

Oracle was the ONLY game in town if you were serious. It was like buying IBM in the 80s. Source: programmed PL/SQL and embedded SQL at the Toronto Stock Exchange in the early 90s, on SCO Unix and Oracle.

it was soooooo the only game in town that they were like NVDA now, yea you got alternatives but you really don't and hence you charge insane prices and everyone is paying up with a grin on their faces. oracle was the only game in town 100% if you were serious!

Nobody was building WoW on FoxPro, c'mon.

You'd have to assume businesses were insane/stupid to go with Oracle to the tune of billions and billions of dollars if you believe that they had zero value to sell.

You can do all of that in fetch really easily with the init object.

   fetch('https://api.example.com/data', {
  headers: {
    'Authorization': 'Bearer ' + accessToken
  }

})

There are pretty much two usage patterns that come up all the time:

1- automatically add bearer tokens to requests rather than manually specifying them every single time

2- automatically dispatch some event or function when a 401 response is returned to clear the stale user session and return them to a login page.

There's no reason to repeat this logic in every single place you make an API call.

Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time.

Finally, there's some nice mocking utilities for axios for unit testing different responses and error codes.

You're either going to copy/paste code everywhere, or you will write your own helper functions and never touch fetch directly. Axios... just works. No need to reinvent anything, and there's a ton of other handy features the GP mentioned as well you may or may not find yourself needing.

Interceptors are just wrappers in disguise.

    const myfetch = async (req, options) => {
        let options = options || {};
        options.headers = options.headers || {};
        options.headers['Authorization'] = token;
    
        let res = await fetch(new Request(req, options));
        if (res.status == 401) {
            // do your thing
            throw new Error("oh no");
        }
        return res;
    }

Convenience is a thing, but it doesn't require a massive library.

That fetch requires so many users to rewrite the same code - that was already handled well by every existing node HTTP client- says something about the standards process.

It could also be trivially written for XMLHttpRequest or any node client if needed. Would be nice if they had always been the same, but oh well - having a server and client version isn't that bad.

Because it is so few lines it is much more sensible to have everyone duplicate that little snippet manually than import a library and write interceptors for that...

(Not only because the integration with the library would likely be more lines of code, but also because a library is a significantly liability on several levels that must be justified by significant, not minor, recurring savings.)

> Because it is so few lines it is much more sensible to have everyone duplicate that little snippet manually

Mine's about 100 LOC. There's a lot you can get wrong. Having a way to use a known working version and update that rather than adding a hundred potentially unnecessary lines of code is a good thing. https://github.com/mikemaccana/fetch-unfucked/blob/master/sr...

> import a library and write interceptors for that...

What you suggesting people would have to intercept? Just import a library you trust and use it.

Your wrapper does do a bunch of extra things that aren't necessary, but pulling in a library here is a far greater maintenance and security liability than writing those 100 lines of trivial code for the umpteenth time.

So yes you should just write and keep those lines. The fact that you haven't touched that file in 3 years is a great anecdotal indicator of how little maintenance such a wrapper requires, and so the primary reason for using a library is non-existent. Not like the fetch API changes in any notable way, nor does the needs of the app making API calls, and as long as the wrapper is slim it won't get in the way of an app changing its demands of fetch.

Now, if we were dealing with constantly changing lines, several hundred or even thousand lines, etc., then it would be a different story.

But you said so yourself they are necessary… otherwise you would just use fetch. This reasoning is going around in circles.

Why the 'but'? Where is the circular reasoning? What are you suggesting we have to intercept?

- Don't waste time rewriting and maintaining code unecessarily. Install a package and use it.

- Have a minimum release age.

I do not know what the issue is.

but it does for massive DDoS :p

> Likewise, every response I get is JSON.

fetch responses have a .json() method. It's literally the first example in MDN: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...

It's literally easier than not using JSON because I have to think about if I want `repsponse.text()` or `response.body()`.

that's such a weak argument. you can write about 20 lines of code to do exactly this without requiring a third party library.

Helper functions seem trivial and not like you’re reimplementing much.

Don't be silly, this is the JS ecosystem. Why use your brain for a minute and come up with a 50 byte helper function, if you can instead import a library with 3912726 dependencies and let the compiler spend 90 seconds on every build to tree shake 3912723 out again and give you a highly optimized bundle that's only 3 megabytes small?

> usage patterns

IMO interceptors are bad. they hide what might get transformed with the API call at the place it is being used.

> Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time.

This is not true unless you are not interfacing with your own backends. even then why not just make a helper that unwraps as json by default but can be passed an arg to parse as something else

One more use case for Axios is it automatically follows redirects, forwarding headers, and more importantly, omiting or rewriting the headers that shouldn't be forwarded for security reasons.

fetch automatically follows redirects, fetch will forward your headers, omitting or rewriting headers is how security breaks… now a scraper got through because it’s masquerading as Chrome.

What does an interceptor in the RequestInit look like?

A wrapper function around fetch… that’s what interceptors are…