Polyfilling setInterval with recursive setTimeout is a classic — and the result is arguably better than the native version.

The implementation

function customSetInterval(callback, delay, ...args) {
  let timerId;
  let cancelled = false;

  function tick() {
    if (cancelled) return;
    callback(...args);
    if (!cancelled) timerId = setTimeout(tick, delay); // reschedule AFTER running
  }

  timerId = setTimeout(tick, delay);

  // return a handle to clear it
  return {
    clear() {
      cancelled = true;
      clearTimeout(timerId);
    },
  };
}

// usage
const interval = customSetInterval(() => console.log("tick"), 1000);
// interval.clear();

The idea: setTimeout runs the callback, and only then schedules the next timeout. It recurses forever until cancelled.

Why this is better than native setInterval

Native setInterval schedules executions on a fixed cadence regardless of how long the callback takes. If the callback takes longer than the interval (or the tab is throttled/busy), executions queue up and fire back-to-back with no gap — "callback stacking."

Recursive setTimeout schedules the next run after the current one finishes, so there's always a full delay gap between executions. No stacking, no overlap. This matters a lot for things like polling an API — you never want a second request firing before the first returns.

Things to get right

• Cancellation — return a handle (or id) with a way to stop it; set a cancelled flag and clearTimeout, so a pending timeout doesn't fire after clear().
• Forward arguments — ...args passed through to the callback, like the real API.
• Re-check cancelled after the callback runs — the callback itself might have cleared the interval.

The framing

"Recursive setTimeout: a tick function that runs the callback, then schedules itself again with setTimeout(tick, delay), repeating until cancelled. I return a handle with a clear() that sets a cancelled flag and clears the pending timeout. The interesting part is this is better than native setInterval — native fires on a fixed cadence and stacks callbacks if one runs long, while recursive setTimeout guarantees a full gap between executions, which is exactly what you want for polling."