Debouncing refers to cleaning up the signal from an opening and closing switch contact so that the cleaned signal matches the intended semantics of the switch action (e.g. one simple press of a button, not fifty pulses).
The analogy here is poor; reducing thrashing in those obnoxious search completion interfaces isn't like debouncing.
Sure, if we ignore everything about it that is not like debouncing, and we still have something left after that, then whatever is left is like debouncing.
One important difference is that if you have unlimited amounts of low latency and processing power, you can do a full search for each keystroke, filter it down to half a dozen results and display the completions. In other words, the more power you have, the less important it is to do any "debouncing".
Switch debouncing is not like this. The faster is your processor at sampling the switch, the more bounces it sees and consequently the more crap it has to clean up. Debouncing certainly does not go away with a faster microcontroller.
It's the term used in frontend dev. It is actually a little worse than you're imagining, because we're not sampling, we're receiving callbacks (so more analogous to interrupts than sampling in a loop). Eg the oninput callback. I've used it for implementing auto save without making a localStorage call on every key press, for example.
I think it makes sense if you view it from a control theory perspective rather than an embedded perspective. The mechanics of the UI (be that a physical button or text input) create a flaggy signal. Naively updating the UI on that signal would create jank. So we apply some hysteresis to obtain a clean signal. In the day way that acting 50 times on a single button press is incorrect behavior, saving (or searching or what have you) 50 times from typing a single sentence isn't correct (or at least undesired).
The example of 10ms is way too low though, anything less than 250ms seems needlessly aggressive to me. 250ms is still going to feel very snappy. I think if you're typing at 40-50wpm you'll probably have an interval of 100-150ms between characters, so 10ms is hardly debouncing anything.
Additionally, regardless of naming, debouncing is an accessibility feature for a surprisingly large portion of the population. Many users who grew up with double-click continue to attempt to provide this input on web forms, because it mostly works. Many more with motor control issues may struggle to issue just a single click reliably, especially on a touchscreen.
Holy moly, for years I've had in the back of my head this thought about why, earlier in my career, I'd see random doubly submitted form submissions on certain projects. Same form code and processing as other sites, legitimate submissions too. Eventually we added more spam filtering and restrictions unrelated to these legitimate ones, but it was probably the double-click users causing those errant submissions. I'd never even have thought of those users. Fascinating
Users of GUI operating systems had been trained to double-click on icons representing applications or files in order to launch them.
If you make a web UI in which a button is styled via an icon image (or otherwise) to look like a launchable application or file, those users will double click on it.
If you make it look like a button, they won't; they were certainly not trained to double-click on [OK] or [Cancel] in an OK/Cancel dialog box, for instance!
Double clicking to launch an action on a file makes sense because you need single click for selecting it. There are things you can do with it other than launch, like dragging it to another location.
T;DR: don't make buttons look like elements that can be selected and dragged somewhere?
--
Another reason: I've sometimes multiply clicked on some button-like thing in a web UI because in spite of working fine, it made no indication that had received the click!
It was styled to look like a button in the unclicked state ... and that one image was all it had.
To detect that the action launched you have to look for clues in the browser status areas showing that something is being loaded. Those are often made unobtrusive these days. Gone are the days of Netscape's spinning planet.
When the user sees that a button doesn't change state upon being clicked, yet the normal cursor is seen (pointer, not hourglass or spinning thing or whatever) they assume that the application has become unresponsive due to a bug or performance problem, or that somehow the click event was dropped; maybe their button is physically not working or whatever.
Yes, it's something pretty much all UI frameworks end up implementing. The easiest way to do it is to simply disable the button at first click until the request is complete. This, of course, also prevents double submissions in cases the user doesn't get enough feedback and clicks again to make sure something actually happened.
I've found that with a sensitive mouse, I unintentionally double click maybe 1 out of 100 times. It's infrequent enough that it rarely causes problems, but every once in a while Murphy's Law gets me. Definitely appreciate UIs that disable the submit button right after first click until it's done processing :-)
The thing about debouncing is that debouncing interrupts from input pins connected directly to e.g. switches is universally a bad idea.
Interrupt pins are weird, level change too slowly? You might never see the interrupt trigger or you'll see it trigger more than once. Switch back and forth many times at a high frequency before settling? Again, you might see interrupts for every switch or you might just get nothing at all. (In summary, directly connecting a noisy switch to an interrupt pin will mean you can lose level transition events.)
To make this work reliably you either need to debounce in hardware before it reaches your interrupt pin or forego interrupts entirely in favour of polling the input pin at a specific speed and keeping a state history.
So the term as it originates in electronics is now both misused and if you do translate it back to electronics it's considered a terrible idea.
For the kind of behaviors they are describing it would. An extra 250ms waiting for an app to load is a lot, but for something like the described autosave behavior, waiting for a 250ms pause in typing before autosaving or making a fetch call is pretty snappy.
An office keyboard's own debouncing could delay a key press 30 ms, and then the OS, software and graphics/monitor hardware would delay it just as much before the user could see the character on screen. So, indeed, 10 ms is much too low.
The delay between key press and sound starts to become noticeable at around 10ms when you play an electronic (musical) keyboard instrument.
At 20-30ms or more, it starts to make playing unpleasant (but I guess for text input it's still reasonable).
50ms+ and it starts becoming unusable or extremely unpleasant, even for low expectations.
I'm not sure how much the perception of delay and the brain lag differs between audio and visual stimuli.
But that's just about the perceived snappiness for immediate interactions like characters appearing on screen.
For events that trigger some more complex visual reaction, I'd say everything below 25ms (or more, depending on context) feels almost instant.
Above 50ms you get into the territory where you have to think about optimistic feedback.
Point that most seem to miss here is that debouncing in FE is often about asynchronous and/or heavy work, e.g. fetching search suggestions or filtering a large, visible list.
Good UIs do a lot of work to provide immediate feedback while debouncing expensive work.
A typical example: when you type and your input becomes longer with the same prefix, comboboxes don't always need to fetch, they can filter if the result set was already smallish.
If your combobox is more complex and more like a real search (and adding characters might add new results), this makes no sense – except as an optimistic update.
_Not_ debouncing expensive work can lead to jank though.
Type-ahead with an offline list of 1000+ search results can already be enough, especially when the suggestions are not just rows of text.
You are right about that, I was also wondering whether the numbers and categories I pulled.. chose make sense.
I was mainly thinking about keyboards where you have at least some close exposure to a/the sound source.
For example, organ players sure need to incorporate some intuition about the pipe sound latency into their skills (on top of the sound space and reverb!)
No, correct debouncing of a hardware button should not add any delay to a single press. It's not wait-then-act, but rather act-then-wait-to-act-again. You're probably thinking of a polling interval (often exacerbated by having key switches wired in a matrix rather than one per pin).
The bouncing behavior itself adds delay. If it takes 30 ms for the switch to settle to a state where it is considered closed according to the debouncing algorithm's parameters, then that's what it is. The algorithm might be "sample every millisecond, until 9 out of 10 samples show "closed". That imposes a minimum delay of 10 ms, and the maximum is whatever it takes for that criterion to be reached.
That's a low pass filter. And I suppose in the type of highly-resilient slow changing signals like OP mentioned in a different comment, it makes sense to do that and even to refer to it as "debouncing". But for general consumer electronic devices with basic local buttons, the standard algorithm is something more like act on the first close, then ignore the next 10 samples. When there is no other reason for a switch to read as closed, the first close means the button has definitely been pushed. The point of debouncing is to avoid seeing the open-close-open-close oscillation afterwards (contacts settling) as their own release-press combos.
Sure, but why does it feel like we're going around in circles here? Labeling that an "asymmetric algorithm" is technically correct but it implies it's some rarer special case. Whereas it's literally just the common debouncing technique, at least when I was learning embedded development ~20 years ago.
And there's no reason for a keyboard to be using anything different. As I said, the real delay factor with keyboard is matrix scanning. If there is a keyboard that has 30ms of latency to register a keypress, I would guess that a ~400Hz (sqrt(104) -> 11 columns?) scanning frequency was as good as could be handled by whatever early cheap USB microcontroller they used, and its designers figured that was good enough for productivity use.
no, when the signal first goes high, the button is immediately considered pressed. The debouncing stops it filters out several transitions after, so that the button stays pressed until the circuit has settled in the low state.
They describe that approach in another comment [1], so I take it to be a descriptive statement about low end keyboards. Perhaps the engineers designing these keyboards view 30ms as an acceptable latency to prevent spurious key presses.
Why would e.g. saving after each keypress be janky from the UI perspective? These days disks can complete a write in 20 us. If you're typing at 0.1 seconds/character, you're going 5,000 times slower than the computer is capable of. If you have a 60 Hz monitor, it can block saving your work every frame and still be 99.9% idle. Even if you're making network requests each time, if the request finishes in 20 ms, you're still done 80 ms before the user presses the next button.
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.
I've programmed my own keyboards, mice and game controllers. If you want the fastest response time then you'd make debouncing be asymmetric: report press ("Make") on the first leading edge, and don't report release ("Break") until the signal has been stable for n ms after a trailing edge. That is the opposite of what's done in the blog article.
Having a delay on the leading edge is for electrically noisy environments, such as among electric motors and a long wire from the switch to the MCU, where you could potentially get spurious signals that are not from a key press.
Debouncing could also be done in hardware without delay, if you have a three-pole switch and an electronic latch.
A better analogy would perhaps be "Event Compression": coalescing multiple consecutive events into one, used when producer and consumer are asynchronous.
Better but not perfect.
Debouncing is established terminology in UI and other event-handling stuff at this point, and has been for a decade. It's a bit too late to complain. Language evolves and not all new uses of words are good analogies.
Yeah. It is not too uncommon for terms to refer to how things were done in the past or in another context. For example, we still "dial" a number on our phone even though rotary phones are no longer used...for other examples see https://en.wikipedia.org/wiki/Misnomer#Older_name_retained
Debouncing is a term of art in UI development and has been for a long time. It is analogous to, but of course not exactly the same as, debouncing in electronics.
It's also worth mentioning that real debouncing doesn't always have to depend on time when you have an analog signal. Instead you could have different thresholds for going from stat A to B vs going from B to A with enough distance between those threshold that you won't switch back and forth during an event. This can even be implemented physically in the switch itself by having separate ON and OFF contacts.
Actually I think it's pretty similar to your example. The "intended semantics" of the search action in that sort of field are to search for the text you enter – not to search for the the side-effects of in-progress partial completion.
Yes, it's not an exact comparison (hence analogy) – but it's not anything worth getting into a fight about.
You debounce a physical switch because it makes contact multiple times before settling in the contacted position, e.g. you might wait until it's settled before acting, or you act upon the first signal and ignore the ones that quickly follow.
And that closely resembles the goal and even implementation of UI debouncing.
It also makes sense in a search box because there you have the distinction between intermediate vs. settled state. Do you act on what might be intermediate states, or do you try to assume settled state?
Just because it might have a more varied or more abstract meaning in another industry doesn't mean it's a bad analogy, even though Javascript is involved, sheesh.
The user intent is usually to get to what they are looking for as quickly as possible. If you intentionally introduce delays by forcing them to enter the complete query or pause to receive intermediate results then you are slowing that down.
> The user intent is usually to get to what they are looking for as quickly as possible.
Yes, and returning 30,000 results matching the "a" they just typed is not going to do that. "Getting the desired result fastest" probably requires somewhere between 2 and 10 characters, context-dependent.
> One important difference is that if you have unlimited amounts of low latency and processing power, you can do a full search for each keystroke,
But you don't want that, as it's useless. Until the user actually finished typing, they're going to have more results than they can meaningfully use - especially that the majority will be irrelevant and just get in the way of real results.
The signal in between is actually, really not useful - at least not on first try when the user is not aware what's in the data source and how can they hack the search query to get their results with minimal input.
No one wants to see results for the letter "a", no one wants their database processing that search, and updating the UI while you're typing can be really distracting.
Don't make assumptions about what the user may or may not want to search for.
E.g. in my music collection I have albums from both !!! [1] and Ø [2]. I've encountered software that "helpfully" prevented me from searching for these artists, because the developers thought that surely noone would search for such terms.
No, you should definitely exercise good judgement in delivering a good UI to the user that doesn't lock up if they happen to type very quickly. But it is context dependent, and sometimes you will want to show them results for "a", sure. "No one" was rhetorical.
In your example, the developers have exercised poor judgment by making a brittle assumption about the data. That's bad. But there is no UX without some model of the user. Making assumptions about user's rate of perception is much safer (in a web app context, it would be a different story in a competitive esports game).
Edit: It does. So, this would be yet another of the squillion-ish examples to support the advice "Please, for the love of god, always enclose your URLs in '<>'.". (And if you're writing a general-purpose URL linkifier, PLEASE just assume that everything between those characters IS part of the URL, rather than assuming you know better than the user.)
I don't believe that they can, not unencoded. Check out the grammar in the relevant RFC[0], as well as the discussion about URL-unsafe characters in the RFC that's updated by 3986 [1], from which I'll quote below.
> Characters can be unsafe for a number of reasons. ... The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text
Also note the "APPENDIX" section on page 22 of RFC1738, which provides recommendations for embedding URLs in other contexts (like, suchas, in an essay, email, or internet forum post.)
Do you have standards documents that disagree with these IETF ones?
If you're using the observed behavior of your browser's address bar as your proof that ">" is valid in a URL, do note that the URL
https://news.ycombinator.com/item?id=44826199>hello there
might appear to contain a space and the ">" character, but it is actually represented as
URLs with the characters ' ' and '>' in them are not valid URLs. Perhaps your web browser does things differently than my Firefox and Chrome instances, but when I copy out that pretty-printed URL from the address bar and paste it, I get the following string:
I don't care if there are results for the letter "a", if they are instant.
Don't become unresponsive after one key to search for results. If the search impacts responsiveness, you need to have a hold-off time before kicking it off so that a longer prefix/infix can be gathered which will reduce the search space and improve its relevance.
Yes. Unless you are pecking at your keyboard your eyes are free to look at the results on the screen and stop typing once you get the result you want. The only thing that's needed is for the results to be stable, i.e. if the top result for "abc" also matches "abcd" then it should also be the top result for "abcd". Unfortunately many search/autocomplete implementations fail at this but that's still a problem even with "debouncing".
It doesn't matter how fast you can read the results, you benefit from instant results as long as you can read them faster than you can complete typing.
Whatever delay you add before showing results doesn't get hidden by the display and user's reading latency, it adds to it.
"Instant," in the context of a user interface, is not zero seconds. It's more like 50ms to 1000ms (depending on the type of information being processed). If you want your user interface to feel snappy and responsive - then you don't want to process things as fast as the computer can, you want to process them in a way that feels instantaneous. If you get caught up processing every keystroke, the interface will feel sluggish.
Be that as it may, the performance side of it becomes irrelevant. The UI responds to the user's keystrokes instantly, and when they type what they had intended to type, the search suggestions are there.
Switch debouncing does not become irrelevant with unlimited computing power.
Switches usually open after closing, so your latch arrangement has to figure out how to unlatch.
At which point you are doing debouncing: distinguishing an intentional switch opening from the bounce that continued after you latched. You need some hold-off time or something.
Also, switches contacts bounce when opening!
A latch could be great for some kind of panic button which indicates a state change that continues to be asserted when the switch opens (and is reset in some other way).
> In electronics, I think we'd use a latch, so it switches high, and stays high despite input change.
RC circuits are more typical, you want to filter out high frequency pulses (indicative of bouncing) and only keep the settled/steady state signal. A latch would be too eager I think.
Thank you for this comment! Suddenly 'bouncing' makes total sense as a mental image when before it only vaguely tracked in some abstract way about tons of tiny events bouncing around and triggering things excitedly until you contain them with debounce() :-)
Come to think of it throttle is the much easier to understand analogy.
Throttling is a different thing though. Debouncing is waiting until the input has stopped occurring so it can run on the final result, throttling is running immediately on the first input and blocking further input for a short duration.
It's a word borrowed for a similar concept. This is so common in software, it is basically the norm. There are hundreds of analogistic terms in software.
Search is a bad example there, a better one would have been clicking a button to add an item to a list, or pressing a shortcut key to do so, where you want to only submit that item once even if someone frantically clicks on the button because they're feeling impatient.
No you should not filter user input like this. Keep user interfaces simple and predictable.
If it really only makes sense to perform the action once than disable/remove the button on the first click. If it makes sense to click the button multiple times then there should be no limit to how fast you can do that. It's really infuriating when crappy software drops user input because its too slow to process one input before the next. There is reason why input these days comes in events that are queued and we aren't still checking if the key is up or down in a loop.
The reality is that language evolves all the time through specialized use and adoption, web development is no different. Every profession and craft builds a pattern language from both borrowed and new terms.
You can explain the phenomenon without patronizing and insulting anyone who works on frontend code.
One thing to watch out for when using debounce/throttle is the poor interaction with async functions. Debounced/throttled async functions can easily lead to unexpected behavior because they typically return the last result they have when the function is called, which would be a previous Promise for an async function. You can get a result that appears to violate causality, because the result of the promise returned by the debounce/throttle will (in a typical implementation) be from a prior invocation that happened before your debounce/throttle call.
There are async-safe variants but the typical lodash-style implementations are not. If you want the semantics of "return a promise when the function is actually invoked and resolve it when the underlying async function resolves", you'll have to carefully vet if the implementation actually does that.
Another thing to watch for is whether you actually need debouncing.
For example, debouncing is often recommended for handlers of the resize event, but, in most cases, it is not needed for handlers of observations coming from ResizeObserver.
I think this is the case for other modern APIs as well. I know that, for example, you don’t need debouncing for the relatively new scrollend event (it does the debouncing on its own).
Debouncing correctly is still super hard, even with rxjs.
There are always countless edge cases that behave incorrectly - it might not be important and can be ignored, but while the general idea of debouncing sounds easy - and adding it to an rxjs observable is indeed straightforward...
Actually getting the desired behavior done via rxjs gets complicated super fast if you're required to be correct/spec compliant
Not really, but I feel like you might've misunderstood me.
The debouncing of rxjs just takes an observation and debounces, which is essentially throttle with inverted output (it outputs last instead of first).
That's almost never what the product owner actually wants, at least IME.
If they give you any kind of soec, you'll quickly realize that limit.
I.e. debouncing after the request happened is impossible, just like cleanly abortion requests on exit or similar.
There are also often a ton of signals you need to add to the observale for all the events the PO wants to respond to, such as opening dialogues, interacting with elements outside of the context of the debounces event chain etc pp
It just keeps getting more complicated with every additional thing they come up with. But if they're fine with just living with the technical limitations, all is fine.
That doesn't sound correct. An async function ought to return a _new_ Promise on each invocation, and each of those returned Promises are independent. Are you conflating memoization? Memoized functions will have these problems with denouncing, but not your standard async function.
this sounds interesting but it's a bit too early here for me. by any chance can we (not simply a royal we :D) ask you to provide a code example (of a correct implementation), or a link to one? many thanks!
I needed an implementation of debounce in Java recently and was surprised to find out that there's no existing decent solution - there's none from the standard library, nor popular utilities libraries like Guava or Apache Commons. There are some implementations floating around like on Stackoverflow but I found them lacking, either there's no thread safety or there's no flexibility in supporting the execution of the task at the leading edge or trailing edge or both. Anyone has a good recommendation on a good implementation?
Maybe searching for throttling return more relevant results? For that there are multiple libraries (e.g. resiliance4j), but you can easily write one yourself as well with a ring buffer.
I've seen the term "request coalescing" used to refer to a technique to minimise the impact of cache stampedes. Protects your backend systems from huge spikes in traffic caused by a cache entry expiring.
Debounce ->
Like when we throw a ball once on ground, but it keeps bouncing,
To prevent that
Human interaction with circuits, sensors, receptors, occur like that
When we click a keyboard key or switch circuit switch the receptors are very sensitive
we feel we did once but during that one press our fingers hands are vibrating multiple times hence the event get registered multiple times due to pulsating, hence all after first event, the second useful event that can be considered legitimate if the idle period between both matches desired debounce delay
in terms of web and software programming or network request handling
it is used as a term to debounce to push away someone something aggresive
Example wise
a gate and a queue
Throttling -> gate get opened every 5 min and let one person in, no matter what
Debounce -> if the persons in queue are deliberately being aggressive thrashing at door to make it open
we push them away
Now instead of 5 min, we tell them you have to wait another 5 min since you are harassing, if before that they try again, we again tell them to wait another 5 min
Thus debounce is to prevent aggresive behaviour
In terms of say client server request over network
We can throttle requests processed by server, let say server will only process requests that happen every 5 min like how apis have limit, during that before 5min no matter how many request made they will be ignored
But if client is aggressive like they keep clicking submit button, keep making 100s of requests that even after throttling server would suffer kind of ddos
so at client side we add debounce to button click event
so even if user keep clicking it being impatient, unnecessary network request will not be made to server unless user stop
Debouncing refers to cleaning up the signal from an opening and closing switch contact so that the cleaned signal matches the intended semantics of the switch action (e.g. one simple press of a button, not fifty pulses).
The analogy here is poor; reducing thrashing in those obnoxious search completion interfaces isn't like debouncing.
Sure, if we ignore everything about it that is not like debouncing, and we still have something left after that, then whatever is left is like debouncing.
One important difference is that if you have unlimited amounts of low latency and processing power, you can do a full search for each keystroke, filter it down to half a dozen results and display the completions. In other words, the more power you have, the less important it is to do any "debouncing".
Switch debouncing is not like this. The faster is your processor at sampling the switch, the more bounces it sees and consequently the more crap it has to clean up. Debouncing certainly does not go away with a faster microcontroller.
It's the term used in frontend dev. It is actually a little worse than you're imagining, because we're not sampling, we're receiving callbacks (so more analogous to interrupts than sampling in a loop). Eg the oninput callback. I've used it for implementing auto save without making a localStorage call on every key press, for example.
I think it makes sense if you view it from a control theory perspective rather than an embedded perspective. The mechanics of the UI (be that a physical button or text input) create a flaggy signal. Naively updating the UI on that signal would create jank. So we apply some hysteresis to obtain a clean signal. In the day way that acting 50 times on a single button press is incorrect behavior, saving (or searching or what have you) 50 times from typing a single sentence isn't correct (or at least undesired).
The example of 10ms is way too low though, anything less than 250ms seems needlessly aggressive to me. 250ms is still going to feel very snappy. I think if you're typing at 40-50wpm you'll probably have an interval of 100-150ms between characters, so 10ms is hardly debouncing anything.
Additionally, regardless of naming, debouncing is an accessibility feature for a surprisingly large portion of the population. Many users who grew up with double-click continue to attempt to provide this input on web forms, because it mostly works. Many more with motor control issues may struggle to issue just a single click reliably, especially on a touchscreen.
Holy moly, for years I've had in the back of my head this thought about why, earlier in my career, I'd see random doubly submitted form submissions on certain projects. Same form code and processing as other sites, legitimate submissions too. Eventually we added more spam filtering and restrictions unrelated to these legitimate ones, but it was probably the double-click users causing those errant submissions. I'd never even have thought of those users. Fascinating
Users of GUI operating systems had been trained to double-click on icons representing applications or files in order to launch them.
If you make a web UI in which a button is styled via an icon image (or otherwise) to look like a launchable application or file, those users will double click on it.
If you make it look like a button, they won't; they were certainly not trained to double-click on [OK] or [Cancel] in an OK/Cancel dialog box, for instance!
Double clicking to launch an action on a file makes sense because you need single click for selecting it. There are things you can do with it other than launch, like dragging it to another location.
T;DR: don't make buttons look like elements that can be selected and dragged somewhere?
--
Another reason: I've sometimes multiply clicked on some button-like thing in a web UI because in spite of working fine, it made no indication that had received the click!
It was styled to look like a button in the unclicked state ... and that one image was all it had.
To detect that the action launched you have to look for clues in the browser status areas showing that something is being loaded. Those are often made unobtrusive these days. Gone are the days of Netscape's spinning planet.
When the user sees that a button doesn't change state upon being clicked, yet the normal cursor is seen (pointer, not hourglass or spinning thing or whatever) they assume that the application has become unresponsive due to a bug or performance problem, or that somehow the click event was dropped; maybe their button is physically not working or whatever.
Yes, it's something pretty much all UI frameworks end up implementing. The easiest way to do it is to simply disable the button at first click until the request is complete. This, of course, also prevents double submissions in cases the user doesn't get enough feedback and clicks again to make sure something actually happened.
I've found that with a sensitive mouse, I unintentionally double click maybe 1 out of 100 times. It's infrequent enough that it rarely causes problems, but every once in a while Murphy's Law gets me. Definitely appreciate UIs that disable the submit button right after first click until it's done processing :-)
The thing about debouncing is that debouncing interrupts from input pins connected directly to e.g. switches is universally a bad idea.
Interrupt pins are weird, level change too slowly? You might never see the interrupt trigger or you'll see it trigger more than once. Switch back and forth many times at a high frequency before settling? Again, you might see interrupts for every switch or you might just get nothing at all. (In summary, directly connecting a noisy switch to an interrupt pin will mean you can lose level transition events.)
To make this work reliably you either need to debounce in hardware before it reaches your interrupt pin or forego interrupts entirely in favour of polling the input pin at a specific speed and keeping a state history.
So the term as it originates in electronics is now both misused and if you do translate it back to electronics it's considered a terrible idea.
> 250ms is still going to feel very snappy
WTF no it won't.
For the kind of behaviors they are describing it would. An extra 250ms waiting for an app to load is a lot, but for something like the described autosave behavior, waiting for a 250ms pause in typing before autosaving or making a fetch call is pretty snappy.
What value would you recommend?
An office keyboard's own debouncing could delay a key press 30 ms, and then the OS, software and graphics/monitor hardware would delay it just as much before the user could see the character on screen. So, indeed, 10 ms is much too low.
The delay between key press and sound starts to become noticeable at around 10ms when you play an electronic (musical) keyboard instrument.
At 20-30ms or more, it starts to make playing unpleasant (but I guess for text input it's still reasonable).
50ms+ and it starts becoming unusable or extremely unpleasant, even for low expectations.
I'm not sure how much the perception of delay and the brain lag differs between audio and visual stimuli.
But that's just about the perceived snappiness for immediate interactions like characters appearing on screen.
For events that trigger some more complex visual reaction, I'd say everything below 25ms (or more, depending on context) feels almost instant.
Above 50ms you get into the territory where you have to think about optimistic feedback.
Point that most seem to miss here is that debouncing in FE is often about asynchronous and/or heavy work, e.g. fetching search suggestions or filtering a large, visible list.
Good UIs do a lot of work to provide immediate feedback while debouncing expensive work.
A typical example: when you type and your input becomes longer with the same prefix, comboboxes don't always need to fetch, they can filter if the result set was already smallish.
If your combobox is more complex and more like a real search (and adding characters might add new results), this makes no sense – except as an optimistic update.
_Not_ debouncing expensive work can lead to jank though.
Type-ahead with an offline list of 1000+ search results can already be enough, especially when the suggestions are not just rows of text.
> 10ms when you play an electronic (musical) keyboard instrument.
Sound travels 3.4 meters in that time; if your speakers are that far away in a live situation, there is your extra 10 ms.
You are right about that, I was also wondering whether the numbers and categories I pulled.. chose make sense.
I was mainly thinking about keyboards where you have at least some close exposure to a/the sound source.
For example, organ players sure need to incorporate some intuition about the pipe sound latency into their skills (on top of the sound space and reverb!)
No, correct debouncing of a hardware button should not add any delay to a single press. It's not wait-then-act, but rather act-then-wait-to-act-again. You're probably thinking of a polling interval (often exacerbated by having key switches wired in a matrix rather than one per pin).
The bouncing behavior itself adds delay. If it takes 30 ms for the switch to settle to a state where it is considered closed according to the debouncing algorithm's parameters, then that's what it is. The algorithm might be "sample every millisecond, until 9 out of 10 samples show "closed". That imposes a minimum delay of 10 ms, and the maximum is whatever it takes for that criterion to be reached.
That's a low pass filter. And I suppose in the type of highly-resilient slow changing signals like OP mentioned in a different comment, it makes sense to do that and even to refer to it as "debouncing". But for general consumer electronic devices with basic local buttons, the standard algorithm is something more like act on the first close, then ignore the next 10 samples. When there is no other reason for a switch to read as closed, the first close means the button has definitely been pushed. The point of debouncing is to avoid seeing the open-close-open-close oscillation afterwards (contacts settling) as their own release-press combos.
Yes; an assymetric algorithm was described upthread by Findecanor, in the grandparent of the comment I replied to:
https://news.ycombinator.com/item?id=44822183
The state machine will report a "make" event early, and then continue to deal with the bounces to detect "break".
Sure, but why does it feel like we're going around in circles here? Labeling that an "asymmetric algorithm" is technically correct but it implies it's some rarer special case. Whereas it's literally just the common debouncing technique, at least when I was learning embedded development ~20 years ago.
And there's no reason for a keyboard to be using anything different. As I said, the real delay factor with keyboard is matrix scanning. If there is a keyboard that has 30ms of latency to register a keypress, I would guess that a ~400Hz (sqrt(104) -> 11 columns?) scanning frequency was as good as could be handled by whatever early cheap USB microcontroller they used, and its designers figured that was good enough for productivity use.
no, when the signal first goes high, the button is immediately considered pressed. The debouncing stops it filters out several transitions after, so that the button stays pressed until the circuit has settled in the low state.
They describe that approach in another comment [1], so I take it to be a descriptive statement about low end keyboards. Perhaps the engineers designing these keyboards view 30ms as an acceptable latency to prevent spurious key presses.
[1] https://news.ycombinator.com/item?id=44822183
Perhaps the people at MDN are 10x typists, with competition-grade gaming keyboards.
Why would e.g. saving after each keypress be janky from the UI perspective? These days disks can complete a write in 20 us. If you're typing at 0.1 seconds/character, you're going 5,000 times slower than the computer is capable of. If you have a 60 Hz monitor, it can block saving your work every frame and still be 99.9% idle. Even if you're making network requests each time, if the request finishes in 20 ms, you're still done 80 ms before the user presses the next button.
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.
I agree that this is a bad analogy.
I've programmed my own keyboards, mice and game controllers. If you want the fastest response time then you'd make debouncing be asymmetric: report press ("Make") on the first leading edge, and don't report release ("Break") until the signal has been stable for n ms after a trailing edge. That is the opposite of what's done in the blog article.
Having a delay on the leading edge is for electrically noisy environments, such as among electric motors and a long wire from the switch to the MCU, where you could potentially get spurious signals that are not from a key press. Debouncing could also be done in hardware without delay, if you have a three-pole switch and an electronic latch.
A better analogy would perhaps be "Event Compression": coalescing multiple consecutive events into one, used when producer and consumer are asynchronous. Better but not perfect.
Debouncing is established terminology in UI and other event-handling stuff at this point, and has been for a decade. It's a bit too late to complain. Language evolves and not all new uses of words are good analogies.
Yeah. It is not too uncommon for terms to refer to how things were done in the past or in another context. For example, we still "dial" a number on our phone even though rotary phones are no longer used...for other examples see https://en.wikipedia.org/wiki/Misnomer#Older_name_retained
That's the same context (making a call to a phone number) with a different implementation.
> for a decade
Whoa!
for anyone else interested in the analog implementation, I found this :)
https://www.digikey.ee/en/articles/how-to-implement-hardware...
Debouncing is a term of art in UI development and has been for a long time. It is analogous to, but of course not exactly the same as, debouncing in electronics.
It's also worth mentioning that real debouncing doesn't always have to depend on time when you have an analog signal. Instead you could have different thresholds for going from stat A to B vs going from B to A with enough distance between those threshold that you won't switch back and forth during an event. This can even be implemented physically in the switch itself by having separate ON and OFF contacts.
Actually I think it's pretty similar to your example. The "intended semantics" of the search action in that sort of field are to search for the text you enter – not to search for the the side-effects of in-progress partial completion.
Yes, it's not an exact comparison (hence analogy) – but it's not anything worth getting into a fight about.
Yeah, I don't get how this thread is at the top.
You debounce a physical switch because it makes contact multiple times before settling in the contacted position, e.g. you might wait until it's settled before acting, or you act upon the first signal and ignore the ones that quickly follow.
And that closely resembles the goal and even implementation of UI debouncing.
It also makes sense in a search box because there you have the distinction between intermediate vs. settled state. Do you act on what might be intermediate states, or do you try to assume settled state?
Just because it might have a more varied or more abstract meaning in another industry doesn't mean it's a bad analogy, even though Javascript is involved, sheesh.
The user intent is usually to get to what they are looking for as quickly as possible. If you intentionally introduce delays by forcing them to enter the complete query or pause to receive intermediate results then you are slowing that down.
> The user intent is usually to get to what they are looking for as quickly as possible.
Yes, and returning 30,000 results matching the "a" they just typed is not going to do that. "Getting the desired result fastest" probably requires somewhere between 2 and 10 characters, context-dependent.
> One important difference is that if you have unlimited amounts of low latency and processing power, you can do a full search for each keystroke,
But you don't want that, as it's useless. Until the user actually finished typing, they're going to have more results than they can meaningfully use - especially that the majority will be irrelevant and just get in the way of real results.
The signal in between is actually, really not useful - at least not on first try when the user is not aware what's in the data source and how can they hack the search query to get their results with minimal input.
No one wants to see results for the letter "a", no one wants their database processing that search, and updating the UI while you're typing can be really distracting.
>No one wants to see results for the letter "a"
Don't make assumptions about what the user may or may not want to search for.
E.g. in my music collection I have albums from both !!! [1] and Ø [2]. I've encountered software that "helpfully" prevented me from searching for these artists, because the developers thought that surely noone would search for such terms.
_______
[1] https://www.discogs.com/artist/207714-!!! ← See? The HN link highlighter also thinks that URLs cannot end with !!!.
[2] https://www.discogs.com/artist/31887-Ø
No, you should definitely exercise good judgement in delivering a good UI to the user that doesn't lock up if they happen to type very quickly. But it is context dependent, and sometimes you will want to show them results for "a", sure. "No one" was rhetorical.
In your example, the developers have exercised poor judgment by making a brittle assumption about the data. That's bad. But there is no UX without some model of the user. Making assumptions about user's rate of perception is much safer (in a web app context, it would be a different story in a competitive esports game).
Let's see if surrounding that URL in the URL-surrounding character pair helps the HN linkifier:
<https://www.discogs.com/artist/207714-!!!>
Edit: It does. So, this would be yet another of the squillion-ish examples to support the advice "Please, for the love of god, always enclose your URLs in '<>'.". (And if you're writing a general-purpose URL linkifier, PLEASE just assume that everything between those characters IS part of the URL, rather than assuming you know better than the user.)
URLs can contain > too.
I don't believe that they can, not unencoded. Check out the grammar in the relevant RFC[0], as well as the discussion about URL-unsafe characters in the RFC that's updated by 3986 [1], from which I'll quote below.
> Characters can be unsafe for a number of reasons. ... The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text
Also note the "APPENDIX" section on page 22 of RFC1738, which provides recommendations for embedding URLs in other contexts (like, suchas, in an essay, email, or internet forum post.)
Do you have standards documents that disagree with these IETF ones?
If you're using the observed behavior of your browser's address bar as your proof that ">" is valid in a URL, do note that the URL
might appear to contain a space and the ">" character, but it is actually represented as behind the scenes. Your web browser is pretty-printing it for you so it looks nicer and is easier to read.[0] <https://datatracker.ietf.org/doc/html/rfc3986#appendix-A>
[1] <https://datatracker.ietf.org/doc/html/rfc1738#section-2.2>
Your point about URL encoding defeats your own other point about these characters being safely parsable as surrounding delimiters
No?
URLs with the characters ' ' and '>' in them are not valid URLs. Perhaps your web browser does things differently than my Firefox and Chrome instances, but when I copy out that pretty-printed URL from the address bar and paste it, I get the following string:
Though -oddly-, while Chrome's pretty-printer does pretty-print %3E, it fails to pretty-print %20 . Go figure.I don't care if there are results for the letter "a", if they are instant.
Don't become unresponsive after one key to search for results. If the search impacts responsiveness, you need to have a hold-off time before kicking it off so that a longer prefix/infix can be gathered which will reduce the search space and improve its relevance.
As a user, I often do want a list to start from a single letter. In a browser address bar, it could start showing items Amazon, Apple, etc.
That is fine. Do you want it to flicker between keystrokes when you're still typing?
Yes. Unless you are pecking at your keyboard your eyes are free to look at the results on the screen and stop typing once you get the result you want. The only thing that's needed is for the results to be stable, i.e. if the top result for "abc" also matches "abcd" then it should also be the top result for "abcd". Unfortunately many search/autocomplete implementations fail at this but that's still a problem even with "debouncing".
Are you really able to scan all the results in a few milliseconds?
Even the 10ms in TFA is too low. I personally wouldn't mind (or probably even notice) a delay of 100 ms.
It doesn't matter how fast you can read the results, you benefit from instant results as long as you can read them faster than you can complete typing.
Whatever delay you add before showing results doesn't get hidden by the display and user's reading latency, it adds to it.
"Instant," in the context of a user interface, is not zero seconds. It's more like 50ms to 1000ms (depending on the type of information being processed). If you want your user interface to feel snappy and responsive - then you don't want to process things as fast as the computer can, you want to process them in a way that feels instantaneous. If you get caught up processing every keystroke, the interface will feel sluggish.
"Flicker" can mean a lot of things, I generally don't have a problem with the list changing while I type.
Consider some people (the type to enable prefers-reduced-motion) find it very difficult to use a UI that is updating too frequently.
> as it's useless
Be that as it may, the performance side of it becomes irrelevant. The UI responds to the user's keystrokes instantly, and when they type what they had intended to type, the search suggestions are there.
Switch debouncing does not become irrelevant with unlimited computing power.
In electronics, I think we'd use a latch, so it switches high, and stays high despite input change.
Doesn't really apply to a search box, where it's more of a delayed event if no event during a specific time window, only keeping last event.
Switches usually open after closing, so your latch arrangement has to figure out how to unlatch.
At which point you are doing debouncing: distinguishing an intentional switch opening from the bounce that continued after you latched. You need some hold-off time or something.
Also, switches contacts bounce when opening!
A latch could be great for some kind of panic button which indicates a state change that continues to be asserted when the switch opens (and is reset in some other way).
> In electronics, I think we'd use a latch, so it switches high, and stays high despite input change.
RC circuits are more typical, you want to filter out high frequency pulses (indicative of bouncing) and only keep the settled/steady state signal. A latch would be too eager I think.
Thank you for this comment! Suddenly 'bouncing' makes total sense as a mental image when before it only vaguely tracked in some abstract way about tons of tiny events bouncing around and triggering things excitedly until you contain them with debounce() :-)
Come to think of it throttle is the much easier to understand analogy.
Throttling is a different thing though. Debouncing is waiting until the input has stopped occurring so it can run on the final result, throttling is running immediately on the first input and blocking further input for a short duration.
thanks - I know :-)
ambiguous phrasing! Just saying of the two throttling is the one that has the more well-known physical analogy
> if you have unlimited amounts of low latency and processing power
And battery, or at least enough air conditioning to cool down the desktop because of those extraneous operations, right?
It's a word borrowed for a similar concept. This is so common in software, it is basically the norm. There are hundreds of analogistic terms in software.
I like you said obnoxious... it is assumed this behaviour is what people want rather than just press a button or hit enter when ready.
Search is a bad example there, a better one would have been clicking a button to add an item to a list, or pressing a shortcut key to do so, where you want to only submit that item once even if someone frantically clicks on the button because they're feeling impatient.
No you should not filter user input like this. Keep user interfaces simple and predictable.
If it really only makes sense to perform the action once than disable/remove the button on the first click. If it makes sense to click the button multiple times then there should be no limit to how fast you can do that. It's really infuriating when crappy software drops user input because its too slow to process one input before the next. There is reason why input these days comes in events that are queued and we aren't still checking if the key is up or down in a loop.
Removing the button from the DOM after click is maybe the worst advice I’ve ever heard for web UX
It’s still a top 10% analogy.
It's basically debouncing plus edge detection.
[flagged]
What a bitter lens with which to view the world.
The reality is that language evolves all the time through specialized use and adoption, web development is no different. Every profession and craft builds a pattern language from both borrowed and new terms.
You can explain the phenomenon without patronizing and insulting anyone who works on frontend code.
You seem to have no idea of how language works, and has worked for as long as there has been language.
One thing to watch out for when using debounce/throttle is the poor interaction with async functions. Debounced/throttled async functions can easily lead to unexpected behavior because they typically return the last result they have when the function is called, which would be a previous Promise for an async function. You can get a result that appears to violate causality, because the result of the promise returned by the debounce/throttle will (in a typical implementation) be from a prior invocation that happened before your debounce/throttle call.
There are async-safe variants but the typical lodash-style implementations are not. If you want the semantics of "return a promise when the function is actually invoked and resolve it when the underlying async function resolves", you'll have to carefully vet if the implementation actually does that.
Another thing to watch for is whether you actually need debouncing.
For example, debouncing is often recommended for handlers of the resize event, but, in most cases, it is not needed for handlers of observations coming from ResizeObserver.
I think this is the case for other modern APIs as well. I know that, for example, you don’t need debouncing for the relatively new scrollend event (it does the debouncing on its own).
Sad that the `scrollend` event isn't supported by Safari and doesn't look to be a part of their release this fall either.
Yep. Apple is a weird organization. scrollend is in Chrome since May 2023 and in Firefox since January 2023.
Reactive programming (such as with RxJS [0]) can be a good solution to this, since they provide primitives that understand time-based dependencies.
[0]: https://rxjs.dev/api/index/function/switchMap
Debouncing correctly is still super hard, even with rxjs.
There are always countless edge cases that behave incorrectly - it might not be important and can be ignored, but while the general idea of debouncing sounds easy - and adding it to an rxjs observable is indeed straightforward...
Actually getting the desired behavior done via rxjs gets complicated super fast if you're required to be correct/spec compliant
can you recommend some reading about the topic? also maybe point to some specs that require (and describe?) fully correct debouncing? thanks!
Not really, but I feel like you might've misunderstood me.
The debouncing of rxjs just takes an observation and debounces, which is essentially throttle with inverted output (it outputs last instead of first).
That's almost never what the product owner actually wants, at least IME.
If they give you any kind of soec, you'll quickly realize that limit.
I.e. debouncing after the request happened is impossible, just like cleanly abortion requests on exit or similar.
There are also often a ton of signals you need to add to the observale for all the events the PO wants to respond to, such as opening dialogues, interacting with elements outside of the context of the debounces event chain etc pp
It just keeps getting more complicated with every additional thing they come up with. But if they're fine with just living with the technical limitations, all is fine.
That doesn't sound correct. An async function ought to return a _new_ Promise on each invocation, and each of those returned Promises are independent. Are you conflating memoization? Memoized functions will have these problems with denouncing, but not your standard async function.
If I understand it correctly, they're saying the debounce function itself usually implements memoization in a way that will return you stale promises.
this sounds interesting but it's a bit too early here for me. by any chance can we (not simply a royal we :D) ask you to provide a code example (of a correct implementation), or a link to one? many thanks!
I would probably look at the lodash implementation (for JS/TS) as a complete implementation example.
https://github.com/lodash/lodash/blob/8a26eb42adb303f4adc7ef...
Damn, there was another thread not too long ago claiming that a sync does not mean concurrent - this would have been a great example to bring up.
So - events / handlers may need to be tagged as "for human interaction"? (to avoid over-filtering signals?)
Such stuff has first-class support in Kotlin: Structured concurrency simplifies multi-threaded programming pretty effectively.
I recently wrote a bit about debouncing fetch using timeouts and AbortController, including small demos, here: https://thomascountz.com/2025/07/02/debouncing-api-calls
https://en.wikipedia.org/wiki/Switch#Contact_bounce
Ooh thanks for the link, didn't know this was where this came from
I needed an implementation of debounce in Java recently and was surprised to find out that there's no existing decent solution - there's none from the standard library, nor popular utilities libraries like Guava or Apache Commons. There are some implementations floating around like on Stackoverflow but I found them lacking, either there's no thread safety or there's no flexibility in supporting the execution of the task at the leading edge or trailing edge or both. Anyone has a good recommendation on a good implementation?
Maybe searching for throttling return more relevant results? For that there are multiple libraries (e.g. resiliance4j), but you can easily write one yourself as well with a ring buffer.
I think it's a fitting analogy. Depends on the intended behaviour, really.
That said, this is a good resource on the original meaning: https://www.ganssle.com/debouncing.htm
I've always used the term Coalescing in the past: https://en.wikipedia.org/wiki/Coalescing_(computer_science)
I've seen the term "request coalescing" used to refer to a technique to minimise the impact of cache stampedes. Protects your backend systems from huge spikes in traffic caused by a cache entry expiring.
And I've used coalesce to describe Array.prototype.reduce and Object.assign as well.
Not sure if anyone else has noticed, but this has been a super popular interview question for front end interviews.
what is so special about this that it is worth posting and garnering 100+ votes?
meta: it seems like this account just submits misc links to mdn?
Debounce -> Like when we throw a ball once on ground, but it keeps bouncing, To prevent that
Human interaction with circuits, sensors, receptors, occur like that
When we click a keyboard key or switch circuit switch the receptors are very sensitive
we feel we did once but during that one press our fingers hands are vibrating multiple times hence the event get registered multiple times due to pulsating, hence all after first event, the second useful event that can be considered legitimate if the idle period between both matches desired debounce delay
in terms of web and software programming or network request handling
it is used as a term to debounce to push away someone something aggresive
Example wise
a gate and a queue Throttling -> gate get opened every 5 min and let one person in, no matter what
Debounce -> if the persons in queue are deliberately being aggressive thrashing at door to make it open we push them away Now instead of 5 min, we tell them you have to wait another 5 min since you are harassing, if before that they try again, we again tell them to wait another 5 min Thus debounce is to prevent aggresive behaviour
In terms of say client server request over network
We can throttle requests processed by server, let say server will only process requests that happen every 5 min like how apis have limit, during that before 5min no matter how many request made they will be ignored
But if client is aggressive like they keep clicking submit button, keep making 100s of requests that even after throttling server would suffer kind of ddos
so at client side we add debounce to button click event
so even if user keep clicking it being impatient, unnecessary network request will not be made to server unless user stop