In JavaScript, what is the difference between repeating work with setInterval(fn, 1000) and having fn schedule itself with setTimeout(fn, 1000) as its last step, and when does that difference matter?

## The two shapes ```js // A: fixed cadence setInterval(fn, 1000); // B: self-rescheduling — a fixed gap between runs (function tick() { fn(); setTimeout(tick, 1000); })(); ``` They look interchangeable and are not. The difference is *what the delay is measured from*. ## What setInterval measures `setInterval` aims at a cadence. Each occurrence is scheduled without reference to how long your callback runs, so the observable spacing is tick start to tick start, not callback end to callback start. If the callback takes 30 ms out of a 100 ms interval, the ticks still land about 100 ms apart and the idle time between them shrinks to about 70 ms. Push the callback to 90 ms and you have 10 ms of headroom left; push it past 100 ms and there is none — the next invocation runs as soon as the current one returns, so the timer effectively becomes a tight loop of back-to-back work. One thing it does **not** do is build a backlog. Because the next occurrence is armed when the current one is dispatched, blocking the main thread for five seconds with a 100 ms interval does not queue fifty catch-up invocations waiting to stampede; you get one late tick and the schedule continues from there. That property is worth stating explicitly in an interview, because "it queues them all up" is a common wrong answer. ## What recursive setTimeout measures The self-rescheduling form arms the next run only after the current one has completed its synchronous work, so the delay is the **gap** between runs. The effective period is `delay + callback duration + lateness`, which means a job taking 300 ms with a 1000 ms delay actually repeats every ~1300 ms. You have traded cadence for a guaranteed breathing space: whatever else is happening, there is always at least `delay` of idle between two runs of your work. ## Neither one is exact Both are built on the same primitive, and in both cases the delay is a **minimum**. The timer only makes your callback eligible to run; it still has to wait for the current task and any queued work ahead of it. So each tick can be late, never early, and with `setInterval` that lateness carries forward into the next scheduling decision — which is exactly why counting `setInterval` ticks is not a way to measure elapsed time. ## Overlap: callbacks never interleave, but their work can JavaScript runs to completion on one thread, so two invocations of the same timer callback never execute simultaneously — the second cannot start until the first has returned. That guarantee is about the *synchronous* body only. If your callback kicks off asynchronous work and returns immediately, the timer will happily start another one while the first is still outstanding, and you can end up with many overlapping operations in flight. ## Why the recursive form usually wins in real code The deciding factor is rarely accuracy — it is that the recursive form gives you a decision point on every cycle: ```js let stopped = false; let delay = 1000; (function tick() { try { doWork(); delay = 1000; // recover after a good run } catch (err) { delay = Math.min(delay * 2, 30_000); // back off after a bad one } if (!stopped) setTimeout(tick, delay); })(); ``` With `setInterval` there is no such point: the delay is fixed at registration, the schedule keeps running whether the work succeeds or fails, and the only lever you have is cancelling the whole thing. Variable delays, exponential backoff, jitter, drift correction, and "stop after N failures" all fall out naturally from the recursive form. ## Cancellation ergonomics `setInterval` is easier to cancel: one handle, valid for the timer's whole life. The recursive form produces a new handle every cycle, so cancellation needs either a mutable variable holding the most recent handle or a boolean flag the next scheduling step consults. That is the one genuine ergonomic advantage of `setInterval` and worth acknowledging rather than pretending the recursive form is free. ## Choosing Reach for `setInterval` when the work is short, fixed-cost, purely synchronous, and cadence matters more than spacing — a UI heartbeat, a cheap re-render of a clock face. Reach for the self-rescheduling `setTimeout` when the callback duration is variable or unbounded, when it starts asynchronous work, when you want backoff or drift correction, or when running two cycles back-to-back with no gap would be harmful.