ky: Like fetch() but less bad

[@Niksorus]

Wait, you guys don't use axios anymore 😂

[@MrXperx]

I had the exact same reaction. Is axios a boomer library now?

[@arpitbharti6245]

​@@MrXperx yeah I've been using raw fetch for years

[@Lexaire]

I still use axios. It has interceptors and shared client instances. I'd have to roll my own in fetch otherwise.

[@nicejungle]

fetch is out since almost 10 years

[@Cameron-hs5ry]

From my reading axios has a couple extra features but for most people either one is fine and accomplishes the same thing. Only reason why I'm considering finally moving off axios is the vulnerabilities that pop up every now and then. Less external dependencies means less maintenance to worry about. Since fetch is built in & requires a similar amount of code to do the same things I'd only consider using Axios if you make use of interceptors & are already familiar with using through Axios and dont care enough to learn how to do something equivalent using Fetch. Using one over the other WONT make or break a project but some people act like it will for some odd reason, its not really a big deal

[@ggnorton7]

It feels more like iteration on Axios than it is on fetch. I see Ky and immediately think “oh it’s just slightly different axios”, at least in terms of using it

[@red_991]

Axios uses XMLHttpRequest, Ky uses fetch. Not the same at all... Axios is a much bigger dependency.

[@ggnorton7]

@@red_991 that’s why I said “in terms of using it”, as if “methods usage and such”

[@marinmiletic9386]

Ky has horribor error handing

[@niels.m]

​@@red_991 I'm pretty sure you're able to make axios use fetch under the hood with recent versions (quite useful when migrating older code to app dir)

[@Bricefriha]

I was about to say 😄

[@itskishank]

XHR is for beta devs. real devs reload their entire page to fetch new data from the server.

[@sunny7268]

🤣🤣🤣🤣🤣🤣🤣

[@ravenblack2153]

its common sense 😆

[@keokawasaki7833]

My company's current project used to do exactly that

[@Tekner436]

ill just pretend thats what im doing by chaining a window.reload after my fetch calls

[@ayasping]

W take 🤣

[@sagiyoav]

I really dont see why should i go all the way from axios just to have another library instead. What's wrong wth axios?

[@nicejungle]

there are people still using axios today ? 😳😳😳

[@Goshified]

Last time I checked, Axios still uses XMLHttpRequest in the browser and http server side. Ky uses fetch and makes things a bit nicer and also supports cool features like hooks into the request lifecycle. If you’re building a larger application, building a custom client on top of ky is totally worth it over axios imo

[@sagiyoav]

@@Goshified why should I care? Ain't fetch and xhr just two ways of communicating with the browser's network module?

[@luderx]

@@sagiyoav try to use axios in react native, and tell me how you feel :)

[@sagiyoav]

@@luderx I don't do r-native :P U know I'm a capacitor kinda guy... Simple worker .

[@0fg4]

I see no problem here. Either way, you’ll have to figure out the wrapper that the team chose to write around the fetch calls. Whether it was made using a library or written from scratch makes little difference. Only with the library you will have better docs.

[@響き合いは今目覚めてく]

+1 so I still prefer fetch for its nativeness

[@TazG2000]

Exactly this - what project is NOT using wrappers of some kind? ky makes it easy to implement common request pre-processing, error handling and such - things that are already unique to each project and would otherwise be done with more effort and boilerplate.

[@joe-robin]

Bruh, what do you mean used, We still use axios 😮

[@joaoqueiroz361]

This must be an ad

[@steve_jabz]

I've been coding for 28 years and I would absolutely use this. Call me a junior dev, idc. I know it wouldn't work in enterprise, I know it's not as easy to outsource, idc. I simply wouldn't work for a company like the one you do in the 1st place. As long as we're making up dumb competitions, using abstractions instead of redundantly typing out the same boilerplate still makes me better than you because I can do more than you in less time and spend the limited time I have on this earth innovating on novel features that are actually interesting instead of maximizing shareholder value. It's like excavators just dropped and you're not gonna use one because experienced hole diggers know they aren't compatible with the guidelines all your coworkers that still use plastic spoons use. Weird flex but ok. I disagree that AI makes fetch the better option. It can easily learn ky from in context learning, and we're not far off it just reading the entire codebase anyway. Simple succinct code only makes it less likely to hallucinate and easier for it or you to debug. It could even trim functions in the library that aren't needed and add them back in when they are.

[@gomesiano]

I really think the example you used between ky vs fetch, in the queryFn, was really simple and in that case makes really no sense to use a wrapper lib. It would be the same case using axios instead of fetch. The reason you would want to use ky is if you want to use it's built-in interceptors (same thing using axios). For example: what if in every request you need to check if your token is valid or something like that. If you only use fetch now you need to build a wrapper for it and what if you also need to log some errors whenever there is an http error, another wrapper you need to build. With ky you can use it's middleware hooks, which are basically interceptors, that makes you do all these things in the same config. With ky, you don't need to build multiple wrappers and also have the possibility to use the onDownloadProgress which fetch doesn't have (another wrapper basically). TLDR: If you need a bunch of interceptors and you want to use the fetch api use ky, if not fetch is enough.

[@dokkenrox]

The fetch API was intended to be somewhat low level. It makes few assumptions about your request, which is a good thing for a low level API, but not really great for everyday development. That being the case, it's hardly surprising that someone would build a library like ky on top of it. What is surprising to me is that so many people continue to use fetch directly in spite of it being pretty inconvenient.

[@diadetediotedio6918]

You know, you can kinda learn anything as basic as this 'ky' in 15 minutes or less. I literally never seen it before and it sounds familiar. So I think there is a larger problem with people self declaring themselves "senior detection machines" or whatever that at the same time are downgrading the world into their own worldviews about how problems should be solved (and that everything outside of that field is "unexperienced"). Put 5 of them in a room and every single one of them will be saying the other is not a real senior very fast. But I get the point, I'm just being a bit harsh.

[@frazuppi4897]

this is bs, just make an util function that includes all the default headers and you have it

[@Akroker1]

@@ramsey2155I mean you could also just use axios

[@isenewotheophilus6485]

That can work too, but..... No thanks

[@frazuppi4897]

@@ramsey2155 so you would use a third party tool instead of writing a function lol? btw this is how our loved shadcn/ui works

[@pokefreak2112]

​@@ramsey2155Yes. Different projects have different requirements. If you use something like ky you'll just end up wrapping it with your own app-specific logic again. You're better off if you just copy-paste the code and modify it to suit your needs instead.

[@kippeneneieren2039]

@@pokefreak2112 lmao just download the package bro, it aint that deep

[@nefthy]

The .json() thing, is convenient but typescript will assume that the thing received matches that type going forward. It might very well be a lie.

[@nefthy]

unknown, while inconvenient is a solid choice as return type. It forces you to check if what you received matches your expectations.

[@gerkim62]

@@nefthy thank you for saying this. People should just use zod. runtime errors are worse than dealing with unknown types

[@ThisAintMyGithub]

Yeah, my thoughts exactly. There would need to be schema validation calls after each one anyway, and at that point you may as well be using tRPC...

[@nefthy]

@@ThisAintMyGithub I'd be comfortable having a schema check, that can be turned off, if the source is trusted. But I'd insist on having the option in order to sleep well at night.

[@jouebien]

To quote ThePrimeTime - "skill issue".

[@thedoctorde]

Axios has fetch adapter now, why change Axios to anything else ?

[@abhishekprajapati6849]

I thought you just took my 13 minutes for nothing. I just needed some patience, beautifully explained! React query in react is a perfect example. It's not about ky vs fetch. Indeed, It's about the analysing associated costs and benefits whenever these kinds of decisions are to be made.

[@williamlvea]

12 lines of code Theo: That's terrifying

[@AshfaqAhmad-sw4vj]

😂😂😂

[@filobonda]

Been using react query for months. It's a life-saver if you're building anything mildly complex.

[@4ortson]

bruh, ofetch solved fetch problems a long time ago

[@rubendacostaesilva8442]

This is the reason why comments sections were created originally, instead of the shitshow it came to be. Never heard of ofetch before. Gave it a try. Loving it.

[@ojvribeiro]

Not only ofetch, but the entire UnJS ecosystem is gold.

[@pauljohnsonbringbackdislik1469]

except upload progress, you still need XHR fallback for stupid loading bar

[@sszzt]

Have been using axios, but after this, it looks like I'll be switching to ky - so clean! Who wants to deal with fetch error handling?! You'd just end up wrapping it yourself anyway.

[@XCanG]

I see positive here because it's not about react, so can be used in vanilla JS.

[@pfqniet]

I wrote my own `ajax()` function in 2009 that wraps XMLHttpRequest. I still use it today with the only change being deleting stuff related to ActiveXObject. Usage: `ajax(url, dataObject).success(result=>{...}).failure(error=>{...});` and that's it. Never needed anything else.

[@PanosPitsi]

No types 💀

[@bagofmanytricks]

It's so easy to make your own common fetch variants for this that you really don't need an extra dependency for it.

Its hilarious that the topic went around and around again and came to react query :D I think default retry and adding "auto headers" is problematic and sometimes react query can be an overkill. Still the best way to async communication is to wrap fetch for the project needs. I think.

[@tie]

Back in my day, we didn't use Axios. We would use the XMLHttpRequest API directly. Or write a tag to the page pointing to an API that responds with JSONP

[@jly_dev]

The `retry` API is so nice

[@hannad]

are you telling me you don't have a wrapper over fetch in your production apps which does all the magic of defaults, error handling, logging, and TS related shit and auth token rotations ?

[@rand0mtv660]

Yeah that part is so weird to me in all of these fetch API discussions. People write code that has 1/10th of the functionality of the library and uses fetch directly all the time and they act like it's comparable.

[@alexbenfaremo5493]

Does everyone write their on production wrapper to fetch data and does all the magic things? I'm doing too but it's kinda weird that no one build a library to do that 🤔

[@immer5680]

So you basically wasted time writing your own library no one understands how to work with? Why?

[@hannad]

@@immer5680 it’s not a library. Bunch of functions that do stuff very specific to product/application. Like logging auth key rotations etc. even if u use this library you would still have to do it

[@immer5680]

@@hannad So your example is irrelevant to the discussion then. Would you write your own wrapper over fetch if you needed hooks, instances, retry, good TS support etc., or just used a library?

[@CassandraTT]

KY, it lubes up the experience of fetch...

[@seannewell397]

All those things you said about the useState -> useQuery transition apply to fetch -> ky inside that same code example... but useQuery gives you enough safety around queryFn that the impact is mitigated but I would argue it's better to control it. It does solve error cases from the API. When you "switched it over to ky" you had _none_ of the proper affordances you needed in your plain fetch call. So it's a bigger win than you are letting on.

[@FinlayDaG33k]

Using Axios? Man, we still had to use XHR for all our requests. :|

[@houstonbova3136]

ky is pretty much how every other language I’ve used does requests. It always cracks me up when a JS breakthrough is just doing something the way everyone else has been doing it for years 🤣

[@Liquidian]

The js ecosystem has had Axios for years. Which seems to have a similar interface to Ky. It has interceptors, ways to setup base configuration, mocking solutions for tests. In other words, what is being shown in the video is nothing new in js.

[@houstonbova3136]

@@Liquidian Oh good to know!

[@punio4]

Sindre Sorhus is the backbone of modern web dev

[@bennobuilder]

Switching to a fetch wrapper isn't very beneficial in plain JavaScript, BUT if you're using TypeScript with an OpenAPI-backed API, a thin wrapper like feature-fetch or openapi-fetch offers full type safety and can be extended with features like retries, delays, functioning as a plugin system 🤷

[@helleye311]

Funny that the comments are split between "wait, people still use axios?" and "wait, people stopped using axios?". I still use axios (and query ofc), but only because headers and error handling and typing is better. Might switch to ky since that seems to handle all of that. Then again, not really sure I need to, axios works, and it's not a huge library (13kb vs 3kb for ky, it's not nothing but if you have one or two functional libraries like framer, three or something for charts, your bundle is already 200kb or more, 5% savings isn't worth the adjustment for me)

[@AntonYefremov]

you missed hooks and its extension mechanism. One can create a narrower private api client by extending a broader public client by using extend and add some hooks (for example to attach additional headers upon extension or at the moment when request is executed). In the same way you can attach an abort signal per request just by extending a private api client. And ky handles all the hooks chains and other pre saved attributes for us. Very nifty

[@guilyCstSenior]

Ky: easing in the hard things.

[@NixinovaMC]

I feel like the point of fetch's verbosity is that its made to be format agnostic and allow stuff like XML request transmissions which I'm sure more people than you think still serve.

[@100timezcooler]

those 39 lines of "boilerplate" are something that you would likely abstract into its own hooks (much like react query) and i think its important new dev to learn how to do that. There should be more of that encouraged. You can still get your 4 lines of code and you dont have to trust some library, and you dont have to guess about what the library is doing.

[@figloalds]

This is almost what I always do first things on a project, wrap fetch with a simple api that I can use with "get(url)", "post(url, data)", but I wrap it in a way that it always treats as content type json and the response is based on the content-type answered by the server, usually string for text/plain or object for application/json What I have been doing all along is just like that, but without the extra .json() call and the extra { json: } in the post data, everything is JSON by default, things that aren't Json I just use fetch instead I never made this into a library because it's really not a big deal

[@aquual1462]

I just use axios with react query

[@MrXperx]

I just use axios. Why use something else? Does fetch support interceptors?

[@puppy0cam]

service workers allow you to intercept fetch requests

[@untlsn]

Fetch by itself not But ky dose by hooks in extend method

[@KaKi87]

@@puppy0cam That's not what Axios interceptors are about.

[@nizomsidiq3]

the advantage of axios or xhr request is that we can listen to the upload progress or download progress, I think fetch didnt have that features. I know this because I used to implement a progressbar for uploading file but for backend i would prefer fetch or considering ky instead of axios

[@KaKi87]

@@nizomsidiq3 Axios also supports fetch so you can use it on backend.

[@grexpex1807]

I don't use ky, i use ramlethal

[@henriquematias1986]

almost every project i do ends up with a function called "post" in my library and one called "get" which is just a wrapper for whatever javascript thing we are using this days to do post or get... i actually felt like going from axios to fetch was a step backwards. i look forward to trying KY. i agree if something is different from native you need a good reason to justify, but KY is definitely one of them.

[@Gorlik1337]

I think ky is for nodejs users. ReactQuery is for react. In that case ky makes sense

[@Lemmy4555]

Who said I want to throw an error on non 20X, constructing an Error is by far the most expensive action in terms of perf in js, and do we really need a library to do retry and timeout? Did we lost the capability to wrap a function in a for loop and use setTimeout and optionally AbortController?

[@sbmb9613]

Significant wins usually come with mastering the lib in question. Abstraction always costs! React query exists but sounds like a react problem ...

[@alihaghjou9767]

Fetch isn’t the problem. How you manage it is and react-query solves it

[@JamminGameDev]

1:57 - literally ran into that yesterday - took me a good 10 minutes before I realized I forgot the content type.

[@volimsir]

For vanilla React, react-query is the way to go. But I found very little need for use it, when building stuff with NextJS.

[@misajid2264]

same here.

[@FaizKhan-of9qv]

the content-type mismatch while dealing with s3 goddamn

[@CottidaeSEA]

I just wrote my own request builder and solved the problem that way. It's easily maintainable and it's easy to use. Took me a few minutes to make and then I kept adding to it as I needed more stuff. There are obviously nice features in these libraries, but how often do you really need them?

[@JoRyGu]

I don't understand the point of adding a dependency for something that would take you like 30 minutes and 20 lines of code to reproduce.

[@HafisCZ]

Because it is 1 line instead of 6! /s Honestly it's quite annoying seeing people using the most unrealistic examples for comparisons between X and Y. There is not a soul who wouldn't spend 10 minutes cleaning this up and writing 3-4 small helpers for this. In the end both would end up with 1 line...

[@BarakaAndrew]

30min is for a 0.5x engineer, more like 5min. It's skill issue at this point

[@weiSane]

Why re write code for everything yet there is already a robust library that can be used .

[@souvikpatrahowrah]

Timeout

[@HatTrex]

​@@weiSane"robust" lmao

[@Chanckjh]

This is why I do ports and adapters. I can easily switch between fetch, axios or something else.

[@bill_and_amanda]

Hmmm I'm still using axios and it's fine, no complaints (granted I am not doing web dev so maybe there's some difference there)

[@_nikeee]

.json() is an Anti-Pattern in TS and explicitly forbidden to do in DefinitelyTyped because passing in a generic parmeter that only sets the return type (and does not depend on the input parameters) is a "hidden" type assertion. It is better to do `.json() as T` because that makes the type assertion visible as type assertions are the boundaries in which errors can sneak in.

[@IbrahimAbdallah-s5e]

It makes total sense to use it in server side

[@alwaisy]

ky: Like fetch() but less horrible.

[@iMagicGraalOnline]

I still use axios because it works really well with react-query

[@steve_jabz]

I use xhr btw

[@jarrodhroberson]

i can tell how senior you are if you argue that NIH Syndrome is a marker for how senior you are.

[@anon_y_mousse]

I can totally see that viewpoint. It's not as big of a win from other libraries, just different, and different slows adoption. One might make a similar case with React Query as compared to Ky, but then if you use React in the first place then you shouldn't be writing vanilla code anyhow and then Query should already be in your toolkit. Of course, in my field, this is one of the reasons why I get angry with junior developers who use C without ever once learning the libraries that make using it faster and easier. Instead I find them rewriting everything from scratch. Unless you genuinely have a better means of accomplishing the task at hand, writing it from scratch, which here would be equivalent to writing vanilla JavaScript, is a big no no.

[@vincent_sz]

I usually just write an simple wrapper function handling all the specifics like headers, error handling, types etc. and just reuse this. No magic and 8kb libs needed

[@chrikke]

I've had to help people countless times where they've used a library for something that the browser already has an api for. It's been a pain every time due to me not understanding how it works, and having to read the docs for the library. Yeah, it's smart. But not everyone wants to learn a new library every time a smart solution is made.

[@pencilcheck]

Theo, I thought react will discard the component of previous render if a prop has changed?? Would it really have a race condition there??

[@MrMudbill]

Yes, because React cannot implicitly abort a network request in transit. The `setState` function is stable across renders, meaning it will just act on the current component render iteration instead of the one where it was "created" in.

[@3_smh_3]

@@MrMudbill this is why I hate react honestly. useState is a huge rabbit hole.

[@pencilcheck]

@@MrMudbill I thought the function will disconnect but didn’t know the state is connected

[@i.reutenko]

tbh I would prefer the openapi-fetch package over ky simply because it creates a contract between FE and BE. I don't need to check if I set the right endpoint path, also I don't need to set the response type manually, and most importantly, when I update the Open API schema, the typescript instantly shows what and where I should change in the codebase

[@i.reutenko]

The only thing that I'd like to change is how we can access the generated types. For now, I've decided to re-export those that I needed from a module with an openapi-fetch setup, but ideally, it would be great to import them from the package, as it was done in Prisma

[@mobythereal]

what you mean "you remember axios" 😭😭 i still use it to this day in every project

[@CrzyMan_Personal]

I'm calling the "Ky" library Kentucky and I refuse to stop

[@untlsn]

Ky and axios have one big advantage over pure fetch - middlewares So you can change request and response on fly

[@leonsantiago8860]

people really into giving edging names for simple wrapper functions

[@YakovFn]

Ky would be great if they added progress bar support in all browsers, however they will have to use xml or only support on chrome

[@rvgn]

Why doesn't .json() take a zod schema? .json() is just a lie waiting to happen.

[@adamfreidin5319]

if the endpoints you're calling happen to be compatible with ky's defaults, great. If not, good luck peeling that onion.

[@jonikyronlahti]

What defaults are you talking about? Non-2xx as errors? It's literally 1 line of code to "unpeel it".

[@rikschaaf]

What if the ky code was part of the browser's standard library? Would that make it better?

[@Adam4]

ky kinda old news. sindre had that and "got" out years back

[@RodrigoLimaBatista]

Me wrapping vue createFetch and just living the good life not caring about random people judgements. :)

[@eip408]

after I saw a content about ky from coderone I think it was last week. I created a custom fetch on top of fetch and called it butter. Since then I stopped using normal fetch lmao🤣

[@ContraHacker1337]

I'd like a follow up to this discussion but including vercel's swr hooks.

[@hawwei5725]

actually in axios@1.7.0 already include fetch adapter

[@rohithkumarbandari]

I always thought that reason for fetch being so bad to work with was it being the first to come. Now that I know axios came first, it makes me think: How bad do the js language designers have to be to replicate a feature that was already made by community and yet do it badly.

[@nickwoodward819]

like 3 years ago "back in the day"

[@professormikeoxlong]

What about ofetch? Anyone heard of that? It uses a nice lib called destr that basically parses the response for you 99% of the time and returns text if it doesn't know

[@OffroadTreks]

Should I lower my head in shame for admitting I'm still using axios in projects?

[@ulicznyinwestor]

Missing piece here would be ky working both in client and server side.

[@ywywywyw612]

Looks pretty cool, but right now I am experimenting with OpenAPI fetch and I like it so far, I use it with my FastAPI backend

[@sorrynotsorry8224]

A couple of years ago, I had the opportunity to migrate a bunch of jQuery ajax calls to fetch. Ky, actually looks interesting and I may consider it in the future if I ever get sick of writing fetch implementations.

[@ericjunior105]

When he said let me ask "chat", I thought he was talking about ChatGPT

[@last.journey]

What about server side rendering in next js

[@unicodefox]

I don't see the point in this being a library. My apps just have a 50 LoC 'api.ts' that defines a function for making API calls, with handling for retrying when the server is unreachable, automatically defines Content-Type, handles session expiry, etc etc.

[@raw_tech_with_tom]

Abort controller and pass signal to fetch . You are good

[@yared172]

I have used ky in one of my projects. It's pretty neat but... It's really an overkill for projects with tanstack-query. Very little DX impove and redundant retries. Ended up ditching it.

[@jonikyronlahti]

They are not solving the same problems at all. Tanstack-query does not fetch data, it triggers, dedupes and caches the "fetches". Ky does none of those, it's the one doing the fetching.

[@nustaniel]

I like how you include everything for the non-React code, but only highlight 4 lines in the React wrapper code and say that's 4 lines of code vs. all 39 in the non-React poorly formatted ChatGPT code, including lines that are blank. Great comparison.

[@ymi_yugy3133]

I don't see how reactQuery has anything to do with fetch vs ky. I can use reactQuery with both or any other data fetching mechanism, e.g. indexDB. I really do detest fetch, but this isn't the solution. What irks me about fetch, is that its error handling is a nightmare. We have the Response type that we need to check for errors, but there are also multiple exceptions. Worst of all type error, which has so many weird combinations of illegal options that I'm sure few can remember them all and which should really be handled by typescript, except the fetch API design is really typescript unfriendly and for some reason type error exceptions also include network errors. Here is what I would want from a fetch API: 1. A type system ensures all http requests are well formed. (*if that is for some quirk not possible, I at least want to be able to check the validity of my request options beforehand) 2. fetch should not throw, but encode all possible errors in an result object, e.g. NetworkEror | Abort | HttpResponse. Don't mix multiple error handling paradigms in the same function. 3. Tangential, but functions like blob, text, json, etc. on the response object should not throw errors, but also fail with a result type. 4. Retries, timeouts should go into wrappers not the fetch API. An abort is sufficient.

[@AndrásMargittai]

I don't feel moving from axios

[@anasouardini]

0:37 nothing can be perfect, tho.

[@SSpirite]

React-query solve so many problems in react, that I even don't know how to perform async in react without it :)

[@CheatCodeSam]

Is this really that “different” as you say it is? I mean you said it yourself that we have been using axios for years. Ky is really just building upon that using fetch underneath.

[@TheMelcool]

Hey , do any of you guys know what font Theo uses in Vscode ? Thanks

[@JoseHenrique-xg1lp]

TBH I think throwing errors for status >= 400 is unnecessary punishing. If client hasn't really failed, why should it handle an error? Ideally we'll acknowledge which response codes may be returned (400, 422, 500) and provide appropriate messages to the user... That said my favourite tool is RTK Query

[@jonikyronlahti]

You can opt-out of non-2xx as errors or you can write your own middleware to handle those cases.

[@backiscute]

axios remains king

[@ashundeyan8031]

I switched to fetch for like 5 minutes a few years ago and then sprinted back to axios... still on axios lmao

[@josephjordell7923]

How can the second request come before the first?