The callback passed to requestAnimationFrame receives a timestamp argument. What is that value, and why should an animation drive motion from it instead of advancing by a fixed amount each frame?

## What the argument is ```js requestAnimationFrame((timestamp) => { console.log(typeof timestamp, timestamp); // "number", e.g. 1832.4 }); ``` The single argument is a `DOMHighResTimeStamp` — a number of milliseconds, with sub-millisecond fractional precision where the browser allows it, measured from the document's *time origin*. That is the same zero point `performance.now()` counts from, so the two are directly comparable: you can subtract a `performance.now()` reading taken earlier from a frame timestamp and get a meaningful duration. It is not a `Date` value and is not affected by the user changing the system clock. ## It stamps the frame, not the call The value is the time at which the current rendering update started, and the browser passes the *same* value to every animation frame callback it invokes for that frame. If three independent components each registered a callback, all three see an identical timestamp even though the second and third actually ran a fraction of a millisecond later. This is deliberate: it means several animations driven by different pieces of code stay perfectly in phase with each other rather than fanning out by however long each callback took. A corollary worth internalising: the timestamp is *not* a measurement of when your code ran. If you need that — to time your own work — call `performance.now()` yourself. If you need a consistent notion of "now" for this frame, use the argument. ## Why fixed per-frame increments break A loop written as `x += 2` moves two pixels per *callback*. The number of callbacks per second is decided by the display, not by you: - 60 Hz display: 120 px/second. - 120 Hz display: 240 px/second — the animation is literally twice as fast, and any duration you promised the designer is halved. - A frame dropped under load: that step never happens, so the object arrives late and, worse, the *speed* visibly wobbles rather than the motion merely stuttering. Delta-time integration fixes all three at once, because the distance travelled becomes a function of the wall clock: ```js const pxPerMs = 0.2; // 200 px per second, on any display let previous = null; function step(now) { if (previous !== null) { x += pxPerMs * (now - previous); } previous = now; // ...write x to the DOM... requestAnimationFrame(step); } requestAnimationFrame(step); ``` On the first callback there is no previous frame, so the delta is undefined — either skip the integration for that one frame, as above, or seed `previous` with the incoming timestamp. ## Duration-based animations For an animation with a known duration, do not accumulate deltas at all; compute progress from a start stamp, which avoids any drift from accumulated floating-point error: ```js let start = null; function fade(now) { if (start === null) start = now; const t = Math.min((now - start) / 300, 1); // 0..1 over 300 ms el.style.opacity = String(t); if (t < 1) requestAnimationFrame(fade); } requestAnimationFrame(fade); ``` Clamping `t` at 1 matters: the last frame before the deadline is rarely exactly on it, so without the clamp you overshoot the final value. ## Where deltas get dangerous Because the delta is real elapsed time, it grows without bound when frames stop being produced — a page that was hidden for a minute, a long blocking task, a heavy garbage-collection pause. Any integration that multiplies by the delta will then take one enormous step. Anything simulation-like should clamp the delta to a sane ceiling, or subdivide it into a bounded number of fixed steps, rather than trusting it blindly. ## Common mistakes Using `Date.now()` instead of the argument gives you a coarser clock that can jump backwards when the system time is adjusted. Reading `performance.now()` at the top of the callback instead of using the argument gives each callback a slightly different "now" and desynchronises animations that should agree. And ignoring the argument entirely — the most common case — is what produces animations that are subtly the wrong speed on exactly the devices you did not test on.