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
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
@@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.
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
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.
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.
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.
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.
@@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.
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.
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.
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.
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 ?
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.
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 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
@@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?
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
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
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 🤷
Been using react query for months. It's a life-saver if you're building anything mildly complex.
2 месяца назад
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.
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
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)
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...
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.
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.
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.
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.
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.
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
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 🤣
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.
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?
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.
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.
.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.
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.
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
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
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
Omfg, how hard is it to just write a function that houses common headers and a fetch() call? You don't need some artisan builder library to do this. Also do developers pay theo to signal boost their libraries? Why does he focus on one library when there are dozens of similar (and arguably better) libraries out there. At least he isn't signal boosting Zod again.
I still feel like fetch is a downgrade in DX from Axios (not comparing to plain XMLHttpRequest, obviously nicer than that). You can't try catch out of the box since 3xx, 4xx isn't considered errors, you have to check response.ok. You can't create instances like you can in axios, with predefined baseUrl and headers. There is no built in interceptors. If the answer to this is "Just build a wrapper", how is this any better than axios?
@@untlsn I understand if bundle size is a big concern, but otherwise it feels like axios already had nailed down a solid way of handling HTTP requests, so why build a new wrapper to do the exact same thing? Of course fetch is a huge upgrade from plain XMLHttpRequests in usability, but almost nobody uses plain XMLHttpRequests anyway. So except from bundle size, I don't see any good reason to switch from axios to fetch at this point.
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
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.
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?
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.
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.
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.
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.
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.
Obviously you wouldn't use a tech stack that is not used in the project you're working on ay work? but at there are used case especially for newer projects?
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
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.
So we are going back to using libraries for simple stuff like, add 2 numbers, isEven. Axios does everything this thing does. And more. And I am not even trying to bash this library. It's cool but unnecessary
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.
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.
It has to be done somewhere. You can extract it to its own function, but it's still "in React." It's also useful to be able to differentiate between different loading/error states in the UI.
@@sub-harmonik you’re right, and in some cases that is what you want to do. In fact, React Query does something similar. It mostly depends on the type of state you’re storing. Taking everything out of components can be a nightmare if you need to reuse a component independently to another. It’s mostly just global state that you want to extract. Exactly how Redux and Zustand and the like work under the hood I haven’t looked into, but I think it’s fair to say that they store state outside of React, and then bring it in when needed. So if that’s what you meant originally, then it’s wrong of me to say it’s still in React.
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🤣
Wait, you guys don't use axios anymore 😂
I had the exact same reaction. Is axios a boomer library now?
@@MrXperx yeah I've been using raw fetch for years
I still use axios. It has interceptors and shared client instances. I'd have to roll my own in fetch otherwise.
fetch is out since almost 10 years
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
XHR is for beta devs. real devs reload their entire page to fetch new data from the server.
🤣🤣🤣🤣🤣🤣🤣
its common sense 😆
My company's current project used to do exactly that
ill just pretend thats what im doing by chaining a window.reload after my fetch calls
W take 🤣
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
Axios uses XMLHttpRequest, Ky uses fetch. Not the same at all... Axios is a much bigger dependency.
@@red_991 that’s why I said “in terms of using it”, as if “methods usage and such”
Ky has horribor error handing
@@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)
I was about to say 😄
this is bs, just make an util function that includes all the default headers and you have it
@@ramsey2155I mean you could also just use axios
That can work too, but..... No thanks
@@ramsey2155 so you would use a third party tool instead of writing a function lol?
btw this is how our loved shadcn/ui works
@@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.
@@pokefreak2112 lmao just download the package bro, it aint that deep
I really dont see why should i go all the way from axios just to have another library instead. What's wrong wth axios?
there are people still using axios today ? 😳😳😳
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
@@Goshified why should I care? Ain't fetch and xhr just two ways of communicating with the browser's network module?
@@sagiyoav try to use axios in react native, and tell me how you feel :)
@@luderx I don't do r-native :P
U know I'm a capacitor kinda guy... Simple worker
.
Bruh, what do you mean used, We still use axios 😮
This must be an ad
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
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.
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.
Axios has fetch adapter now, why change Axios to anything else ?
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.
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.
unknown, while inconvenient is a solid choice as return type. It forces you to check if what you received matches your expectations.
@@nefthy thank you for saying this. People should just use zod. runtime errors are worse than dealing with unknown types
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...
@@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.
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.
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.
bruh, ofetch solved fetch problems a long time ago
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.
Not only ofetch, but the entire UnJS ecosystem is gold.
except upload progress, you still need XHR fallback for stupid loading bar
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 ?
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.
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 🤔
So you basically wasted time writing your own library no one understands how to work with? Why?
@@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
@@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?
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
I see positive here because it's not about react, so can be used in vanilla JS.
It's so easy to make your own common fetch variants for this that you really don't need an extra dependency for it.
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
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 🤷
Using Axios? Man, we still had to use XHR for all our requests. :|
Been using react query for months. It's a life-saver if you're building anything mildly complex.
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.
I just use axios. Why use something else? Does fetch support interceptors?
service workers allow you to intercept fetch requests
Fetch by itself not
But ky dose by hooks in extend method
@@puppy0cam That's not what Axios interceptors are about.
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
@@nizomsidiq3 Axios also supports fetch so you can use it on backend.
To quote ThePrimeTime - "skill issue".
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)
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.
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...
30min is for a 0.5x engineer, more like 5min. It's skill issue at this point
Why re write code for everything yet there is already a robust library that can be used .
Timeout
@@weiSane"robust" lmao
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.
No types 💀
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.
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.
I think ky is for nodejs users. ReactQuery is for react. In that case ky makes sense
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.
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.
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
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 🤣
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.
@@Liquidian Oh good to know!
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?
12 lines of code
Theo: That's terrifying
😂😂😂
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.
I just use axios with react query
For vanilla React, react-query is the way to go. But I found very little need for use it, when building stuff with NextJS.
same here.
The `retry` API is so nice
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.
.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.
KY, it lubes up the experience of fetch...
Significant wins usually come with mastering the lib in question. Abstraction always costs! React query exists but sounds like a react problem ...
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.
I don't use ky, i use ramlethal
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
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
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
You can opt-out of non-2xx as errors or you can write your own middleware to handle those cases.
Omfg, how hard is it to just write a function that houses common headers and a fetch() call? You don't need some artisan builder library to do this. Also do developers pay theo to signal boost their libraries? Why does he focus on one library when there are dozens of similar (and arguably better) libraries out there. At least he isn't signal boosting Zod again.
Fetch isn’t the problem. How you manage it is and react-query solves it
This is why I do ports and adapters. I can easily switch between fetch, axios or something else.
1:57 - literally ran into that yesterday - took me a good 10 minutes before I realized I forgot the content type.
Why doesn't .json() take a zod schema? .json() is just a lie waiting to happen.
Ky: easing in the hard things.
I still feel like fetch is a downgrade in DX from Axios (not comparing to plain XMLHttpRequest, obviously nicer than that).
You can't try catch out of the box since 3xx, 4xx isn't considered errors, you have to check response.ok.
You can't create instances like you can in axios, with predefined baseUrl and headers.
There is no built in interceptors.
If the answer to this is "Just build a wrapper", how is this any better than axios?
Its build in and way way smaller
You can reproduce api axios using fetch in much less code
@@untlsn I understand if bundle size is a big concern, but otherwise it feels like axios already had nailed down a solid way of handling HTTP requests, so why build a new wrapper to do the exact same thing?
Of course fetch is a huge upgrade from plain XMLHttpRequests in usability, but almost nobody uses plain XMLHttpRequests anyway.
So except from bundle size, I don't see any good reason to switch from axios to fetch at this point.
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
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.
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?
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)
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.
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.
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.
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.
what you mean "you remember axios" 😭😭 i still use it to this day in every project
I use xhr btw
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.
I'd like a follow up to this discussion but including vercel's swr hooks.
the content-type mismatch while dealing with s3 goddamn
Obviously you wouldn't use a tech stack that is not used in the project you're working on ay work? but at there are used case especially for newer projects?
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
Non-2xx as errors sounds weird, I didn’t think 1xx and 3xx codes were considered request errors
i can tell how senior you are if you argue that NIH Syndrome is a marker for how senior you are.
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
What if the ky code was part of the browser's standard library? Would that make it better?
I still use axios because it works really well with react-query
actually in axios@1.7.0 already include fetch adapter
people really into giving edging names for simple wrapper functions
It makes total sense to use it in server side
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.
if the endpoints you're calling happen to be compatible with ky's defaults, great. If not, good luck peeling that onion.
What defaults are you talking about? Non-2xx as errors? It's literally 1 line of code to "unpeel it".
Ky and axios have one big advantage over pure fetch - middlewares
So you can change request and response on fly
Me wrapping vue createFetch and just living the good life not caring about random people judgements. :)
I'm calling the "Ky" library Kentucky and I refuse to stop
Missing piece here would be ky working both in client and server side.
So we are going back to using libraries for simple stuff like, add 2 numbers, isEven. Axios does everything this thing does. And more. And I am not even trying to bash this library. It's cool but unnecessary
Why add the extra 10 kb to your bundle?
Theo, I thought react will discard the component of previous render if a prop has changed?? Would it really have a race condition there??
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.
@@MrMudbill this is why I hate react honestly. useState is a huge rabbit hole.
@@MrMudbill I thought the function will disconnect but didn’t know the state is connected
0:37 nothing can be perfect, tho.
When he said let me ask "chat", I thought he was talking about ChatGPT
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.
I don't usually do frontend but it's weird to me that people often use react components for getting/managing state
It has to be done somewhere. You can extract it to its own function, but it's still "in React." It's also useful to be able to differentiate between different loading/error states in the UI.
so what to use? rather, why even use react if you don't need its state?
@@MrMudbill isn't the whole point of things like redux to extract state back out of components?
@@sub-harmonik you’re right, and in some cases that is what you want to do. In fact, React Query does something similar. It mostly depends on the type of state you’re storing. Taking everything out of components can be a nightmare if you need to reuse a component independently to another. It’s mostly just global state that you want to extract. Exactly how Redux and Zustand and the like work under the hood I haven’t looked into, but I think it’s fair to say that they store state outside of React, and then bring it in when needed. So if that’s what you meant originally, then it’s wrong of me to say it’s still in React.
ky: Like fetch() but less horrible.
Abort controller and pass signal to fetch . You are good
ky kinda old news. sindre had that and "got" out years back
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
I switched to fetch for like 5 minutes a few years ago and then sprinted back to axios... still on axios lmao
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🤣
like 3 years ago "back in the day"
I don't feel moving from axios
Should I lower my head in shame for admitting I'm still using axios in projects?
Hey , do any of you guys know what font Theo uses in Vscode ?
Thanks