Debounce
Analogy: Hardware vs UI Debouncing
- Several commenters argue the MDN analogy to hardware switch debouncing is weak:
- In UI/search, more compute and lower latency make debouncing less necessary.
- In hardware, faster sampling exposes more bounces and debouncing never goes away.
- Others defend it as “good enough”: both cases turn a noisy, bursty signal (keypresses, callbacks) into behavior that better matches human intent.
- Hardware details come up:
- Common approach is asymmetric: act immediately on first “press” edge, then ignore subsequent bounces while carefully detecting “release”.
- RC filters, hysteresis thresholds, latches, and matrix scanning vs interrupts are discussed as practical tradeoffs.
- Contacts bounce on both closing and opening, so both edges need handling.
UX, Latency, and Appropriate Delays
- There’s strong disagreement over timings:
- Some say 10ms is far too low for frontend debouncing; suggest ~100–250ms for things like autosave or API-backed search.
- Others think 250ms “snappy” is wrong and want updates as close to instantaneous as hardware allows.
- Perception examples: keyboard latency, musical instruments, and display refresh are used to reason about when delays become noticeable or unpleasant.
- Some users like live-updating search and navigation from the very first character; others find rapid result changes distracting and argue early queries (“a”) mostly waste compute and attention.
- Accessibility angle: debouncing protects users who double-click out of habit or due to motor issues; disabling submit buttons after click is a common pattern, especially when feedback is otherwise subtle.
Performance and When to Debounce
- One camp holds that local operations (e.g., small local search, localStorage writes) don’t need debouncing and feel best when truly immediate.
- Another camp stresses:
- Slow networks, heavy rendering, and constrained devices can make per-keystroke work janky.
- Debouncing saves bandwidth and backend resources.
- Some APIs (ResizeObserver, scrollend) already coalesce, so extra debouncing is unnecessary.
Async, Reactive, and Terminology
- Debounced/throttled async functions can return stale Promises if implementations reuse the last one; this can confuse callers about which input produced which result.
- Reactive tools (e.g., RxJS operators) help with time-based composition, but “fully correct” behavior quickly becomes complex and spec-dependent.
- Distinctions are emphasized:
- Debounce: wait for silence, then act on the last event.
- Throttle: act immediately, then suppress for a period.
- Some suggest “event compression” or “coalescing” as more precise terms, but “debounce” is now entrenched frontend jargon.