Local storage is a poor example because it updates in the background and wouldn’t necessarily change your UI much. But if a design calls for a search to be made while a user types that would get janky fast.
React in particular is data driven so in the above example, if you make the api call on each keypress, and save it into state or whatever, the UI will update automatically. I can type 70 words per minute. Nobody wants the search results to update that fast. (Should we be building searches that work this way? Often you have no choice.) A slow network + a short search string + a not top of the line device like a cheap phone means a really janky experience. And even if it’s not janky, its a waste of your users bandwidth (not everybody has unlimited) and an unnecessary drain on your server resources.
Even though we say “update as the user types” people type in bursts. There’s no reason not to debounce it, and if you can make the debounce function composable, you can reuse it all over the place. It’s a courtesy to the users and a good practice.
I type around 90-100 wpm and I appreciate that clementine player for example doesn't seem to have any delay except apparently when querying radio stations (which is described as "to be polite"). When searching your own library, it updates immediately (I'd be very surprised if the query weren't faster than my monitor refresh). My only perception is that it's fast. I don't know why anyone would see it as janky.
So it seems to me that it's entirely about not wasting resources/to be polite. In the limit where you have a computer that can do its work faster than your display refreshes, letting it do so seems to clearly make everything feel snappier.
No one's typing quickly on a phone anyway and most people probably do a word at a time, and that word will come in slower than your denounce, so again there is no point in delaying it.
One thing another user pointed out is that your search does need to be stable. An exact substring match shouldn't randomly get bumped down as you type more.
A separate issue you might encounter for slow queries is that requests might get blocked behind each other such that your new query is queued before you even submitted the previous one. In that case it makes sense to cancel the unsent one (and if very expensive, perhaps when the sent ones), but I don't know that web browsers can tell you whether a request is queued or in-flight or give you meaningful lifecycle hooks. Obviously normal programs have a lot more flexibility in how to handle this. But this is also not the case posited originally, which is low latency/fast processing.
Introducing auto save into the discussion may have been confusing, you're both right that that wouldn't generally cause jank, debouncing an auto save is more about not using resources unnecessarily and may help provide a better edit history depending on how you've written the application.
React in particular is data driven so in the above example, if you make the api call on each keypress, and save it into state or whatever, the UI will update automatically. I can type 70 words per minute. Nobody wants the search results to update that fast. (Should we be building searches that work this way? Often you have no choice.) A slow network + a short search string + a not top of the line device like a cheap phone means a really janky experience. And even if it’s not janky, its a waste of your users bandwidth (not everybody has unlimited) and an unnecessary drain on your server resources.
Even though we say “update as the user types” people type in bursts. There’s no reason not to debounce it, and if you can make the debounce function composable, you can reuse it all over the place. It’s a courtesy to the users and a good practice.