7 ms·
Debounce
- deleted 1y ago[deleted]
- kazinator 1y agoDebouncing 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.
- maxbond 1y agoIt'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.
- Findecanor 1y agoAn 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.
- maxbond 1y agoPerhaps the people at MDN are 10x typists, with competition-grade gaming keyboards.
- mindslight 1y agoNo, 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).
- maxbond 1y agoThey 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 https://news.ycombinator.com/item?id=44822183
- kazinator 1y agoThe 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.
- mindslight 1y agoThat'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.
- jiehong 1y agoIn 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.
- naasking 1y ago> 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.
- kazinator 1y agoSwitches 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).
- Tade0 1y ago> 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.
- maxbond 1y agoNo 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.
- meindnoch 1y ago>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- 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-Ø https://www.discogs.com/artist/31887-Ø
- simoncion 1y agoLet's see if surrounding that URL in the URL-surrounding character pair helps the HN linkifier: <https://www.discogs.com/artist/207714-!!! 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.)
- Findecanor 1y agoI 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.
- Sharlin 1y agoDebouncing 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.
- em3rgent0rdr 1y agoYeah. 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 https://en.wikipedia.org/wiki/Misnomer#Older_name_retained
- kazinator 1y agoThat's the same context (making a call to a phone number) with a different implementation.
- kazinator 1y ago> for a decade Whoa!
- 1y ago
- haileys 1y agoDebouncing 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.
- amelius 1y agoIt's basically debouncing plus edge detection.
- jon-wood 1y agoSearch 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.
- account42 1y agoNo 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.
- sgammon 1y agoRemoving the button from the DOM after click is maybe the worst advice I’ve ever heard for web UX
- matthewmacleod 1y agoActually 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.
- account42 1y agoThe 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.
- naasking 1y ago> 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.
- hombre_fatal 1y agoYeah, 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.
- meindnoch 1y ago[flagged]
- soulofmischief 1y agoWhat 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.
- Sharlin 1y agoYou seem to have no idea of how language works, and has worked for as long as there has been language.
- bravesoul2 1y agoI like you said obnoxious... it is assumed this behaviour is what people want rather than just press a button or hit enter when ready.
- account42 1y agoIt'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.
- davnicwil 1y agoThank 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.
- Izkata 1y agoThrottling 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.
- davnicwil 1y agothanks - I know :-) ambiguous phrasing! Just saying of the two throttling is the one that has the more well-known physical analogy
- kube-system 1y agoIt'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.
- rayiner 1y agoIt’s still a top 10% analogy.
- nottorp 1y ago> 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?
- achou 1y agoOne 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.
- pas 1y agothis 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!
- tracker1 1y agoI would probably look at the lodash implementation (for JS/TS) as a complete implementation example. https://github.com/lodash/lodash/blob/8a26eb42adb303f4adc7ef56e300f14c5992aa68/lodash.js#L10372 https://github.com/lodash/lodash/blob/8a26eb42adb303f4adc7ef...
- cnity 1y agoReactive 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 https://rxjs.dev/api/index/function/switchMap
- ffsm8 1y agoDebouncing 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
- fnord77 1y agohttps://en.wikipedia.org/wiki/Switch#Contact_bounce https://en.wikipedia.org/wiki/Switch#Contact_bounce
- Oxodao 1y agoOoh thanks for the link, didn't know this was where this came from
- thomascountz 1y agoI 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://thomascountz.com/2025/07/02/debouncing-api-calls
- G_o_D 1y agoDebounce -> 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
- _def 1y agoI 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 https://www.ganssle.com/debouncing.htm
- lma21 1y agoI've always used the term Coalescing in the past: https://en.wikipedia.org/wiki/Coalescing_(computer_science) https://en.wikipedia.org/wiki/Coalescing_(computer_science)
- joeframbach 1y agoAnd I've used coalesce to describe Array.prototype.reduce and Object.assign as well.
- ultrafez 1y agoI'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.
- ncann 1y agoI 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?
- gf000 1y agoMaybe 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.
- game_the0ry 1y agoNot sure if anyone else has noticed, but this has been a super popular interview question for front end interviews.
- Pwntastic 1y agowhat 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?