A teammate replaces a 300 ms debounce on an expensive filtered list with React 19's startTransition and says the two are equivalent. How do they actually differ in what work runs and what the user sees?
answer
- one is a timer, one is a priority
- start later versus interrupt mid-flight
- adapts to the device, no fixed delay
- reduces nothing — same renders, same requests
basics
~20 sA debounce postpones starting the work until the user pauses; a transition starts it immediately but at a priority React can interrupt and discard. So a transition shows fresh results as fast as the machine allows and never inserts an artificial wait, while a debounce is a fixed guess at how long to stall.
solid answer
~50 sA debounce is a timer: nothing happens for 300 ms, then the full render runs at normal priority and blocks the main thread for however long it takes. `startTransition` inverts both halves. The render starts on the very next keystroke, so on a fast machine the user sees results sooner than any debounce would allow; and because the render is non-urgent, React can pause it mid-tree to handle the next keypress and abandon the work if the value changed again. That is interruption after the work has begun, which a timer cannot do. Practical consequences: a transition self-tunes to the device instead of hardcoding a delay, it exposes a real pending flag through `useTransition`, and it keeps the previous results interactive meanwhile. A debounce still has a place for things you genuinely want to fire less often, such as network requests — transitions reduce nothing.
code
jsx · 26 linesimport { useState, useTransition } from 'react';
export function FilteredList({ items }) {
const [query, setQuery] = useState('');
const [term, setTerm] = useState('');
const [isPending, startTransition] = useTransition();
function handleChange(event) {
const next = event.target.value;
setQuery(next);
startTransition(() => setTerm(next));
}
const shown = items.filter((item) => item.includes(term));
return (
<div>
<input value={query} onChange={handleChange} />
<ul style={{ opacity: isPending ? 0.6 : 1 }}>
{shown.map((item) => (
<li key={item}>{item}</li>
))}
</ul>
</div>
);
}go deeper
Recall the one-line contrast: a debounce waits before starting, a transition starts immediately at a priority React can interrupt. Do not describe startTransition as a delay.
Explain both axes — when work begins and what may happen to it mid-flight — and name the concrete consequences: device-adaptive latency, discarded stale renders, and a pending flag that comes with the mechanism.
Show the judgment that debouncing survives for anything with a per-call cost outside rendering, and that swapping it out to "modernise" a search box can quietly multiply server traffic.
Own the policy question: which responsiveness problems belong to render scheduling and which to request shaping, and how you stop a codebase accumulating overlapping ad-hoc timers that fight the scheduler.
## The two mechanisms A **debounce** wraps a function in a timer. Each call clears the pending timer and sets a new one; the wrapped function runs only once the caller has been quiet for the chosen interval. Nothing about the work itself changes — when it finally runs, it runs to completion at ordinary priority. **`startTransition`** does not touch timing at all. Updates scheduled inside its callback are tagged non-urgent. React begins rendering them right away, but it is allowed to yield the main thread between units of work, to let an urgent update jump the queue, and to abandon a partly-built render whose input is now stale. So the two differ on both axes: *when the work starts* and *what can happen to it once started*. ## Difference 1: latency on a fast machine With a 300 ms debounce, a user who types one character and stops waits 300 ms before anything renders, on every device, forever. The number is a guess about the slowest machine you care about, applied to all of them. With a transition, the render starts immediately; on a laptop where filtering takes 20 ms the results are on screen in 20 ms. The mechanism adapts to the hardware instead of encoding an assumption about it. ## Difference 2: interruption versus prevention A debounce prevents work from starting. A transition permits work to be *abandoned*. If the user types `a`, React begins rendering the list for `a`; when `b` arrives mid-render, React stops, discards the partial tree, and restarts for `ab`. Nothing incomplete is ever committed, and the keystroke was never blocked. This is the capability a timer cannot reproduce. Once a debounced callback fires and a synchronous render begins, the browser is committed to finishing it — the next keypress waits behind it. That is precisely the jank people notice when a debounce still "feels sticky" during sustained typing. ## Difference 3: the pending signal A debounce gives you no principled way to know that a stale view is on screen; teams usually bolt on an extra `isSearching` state and try to keep it in sync with the timer. `useTransition` returns the pending flag as part of the mechanism: ```jsx const [isPending, startTransition] = useTransition(); // … <div style={{ opacity: isPending ? 0.6 : 1 }}> <BigFilteredList term={filterTerm} /> </div> ``` The flag is true from the moment the transition is scheduled until React commits the resulting render, so the dimming exactly brackets the stale interval. ## Difference 4: what stays on screen During a debounce's dead interval and during a transition's background render, the user sees the previous results — that part is the same. The difference is that under a transition the previous UI stays fully interactive and React is actively making progress on the replacement; under a debounce, nothing is happening at all and the app is merely waiting out a clock. ## What a transition does not do This is where candidates over-claim. A transition: - does **not** make the render cheaper — the same components render the same number of times; - does **not** move work off the main thread — there is no worker involved; - does **not** reduce how often anything is *requested*. That last point is why debouncing has not disappeared. If each keystroke triggers a network call, a rate-limited API, or an analytics event, you want fewer of them to happen — and only a timer-based technique reduces the count. Transitions govern render priority; they are not a rate limiter. The two are complementary, and real search UIs frequently debounce the request while marking the resulting render as a transition. ## Throttling, briefly Throttling — run at most once per interval — differs from both: it guarantees periodic progress rather than quiet-period batching. Against a transition the same analysis applies, because it is still a timing policy over when work starts, with no ability to interrupt work already underway. ## How to answer the teammate The honest summary is that they solve overlapping symptoms with opposite strategies. A debounce trades guaranteed latency for guaranteed fewer starts. A transition trades nothing away: it starts eagerly and relies on interruptibility to stay responsive, which is strictly better *for render cost* and does nothing at all for *request cost*. Replacing a debounce that existed to protect a server is a regression; replacing one that existed to protect the main thread from a slow render is an upgrade.
- When would you keep the debounce and add a transition alongside it?When each keystroke triggers something you genuinely want to fire less often — a network request, a rate-limited API, an analytics event. Debounce the request so fewer are sent, and mark the state update that renders the results as a transition so the resulting render cannot block typing. They address different costs.
- Does a transition guarantee the app stays at sixty frames per second?No. React can only yield between units of work, so a single component whose render takes 200 ms still blocks the frame once started. Transitions remove the coupling between an urgent update and a slow one; they do not bound the cost of any individual render.
- How does the user-visible latency of the two compare when the machine is slow?They converge. On a device where the render itself takes longer than the debounce interval, the dominant cost is the render, not the wait, so both feel slow — but the transition still keeps the input responsive while it works, whereas the debounced render blocks the keyboard once it starts.
saying these in an interview costs you the question
- Calls startTransition "a debounce with better syntax"
- Says a transition delays the update by an interval
- Claims transitions reduce the number of renders
- Thinks a transition throttles network requests
- Says the work runs on a background thread