Several floating panels on a page each position themselves in a scroll listener by reading `getBoundingClientRect()` on their anchor element and then writing `style.transform` on the panel, and scrolling stutters badly. How would you restructure that with `requestAnimationFrame` so the page performs at most one layout per frame?

## What is actually wrong with the naive version The handler as written has two independent defects that compound. **Too often.** Scroll events can be dispatched many times between two screen updates. Every one of those runs the full positioning work, and every intermediate result is thrown away — the user only ever sees the last one before the frame is drawn. **Wrong order.** Each panel reads its anchor's rectangle and then writes its own transform. With several panels, that becomes read, write, read, write. The write leaves style and layout dirty; the next panel's `getBoundingClientRect()` is contractually obliged to return a current rectangle, so the browser flushes synchronously before answering. N panels produce N flushes — per event, not per frame. ## Step one: one update per frame ```js let scheduled = false; function onScroll() { if (scheduled) return; scheduled = true; requestAnimationFrame(() => { scheduled = false; update(); }); } window.addEventListener('scroll', onScroll, { passive: true }); ``` The flag is the important part. Without it, a burst of ten scroll events queues ten callbacks and you have coalesced nothing. With it, the listener is a couple of instructions and all the real work happens once, in the frame callback. Using `requestAnimationFrame` rather than a timer matters here because visual updates should be tied to when the browser is about to render, not to an arbitrary delay that can land at any point relative to the frame. ## Step two: measure everything, then mutate everything ```js function update() { const rects = pairs.map(({ anchor }) => anchor.getBoundingClientRect()); // reads pairs.forEach(({ panel }, i) => { // writes panel.style.transform = `translate(${rects[i].left}px, ${rects[i].bottom}px)`; }); } ``` Now the first read pays for at most one flush, every remaining read runs against clean layout, and no write is ever observed before the browser's own rendering steps. The layout count per frame is one, no matter how many panels there are. Note the discipline this imposes: the measurement and the mutation for one widget are no longer adjacent in the code. That is the point, and it is why a well-meaning helper like `positionPanel(panel)` — which measures and writes for a single widget — quietly reintroduces the problem the moment a caller loops over it. The phase split has to hold across components, not just inside one function. ## Why reads must come before writes even for transform It is tempting to assume that writing `style.transform` is harmless because transforms are cheap to render. Do not rely on that for the ordering rule: `getBoundingClientRect()` reports the element's transformed, viewport-relative box, so after any style write the browser still has to bring style up to date before it can answer, and it will run layout too if layout is dirty. The safe rule is unconditional — **all reads, then all writes** — because it does not depend on knowing which properties invalidate what. ## Pitfalls worth naming - **No guard flag.** Scheduling a callback per event coalesces nothing. - **Forgetting to clear the flag** inside the callback, so no further updates are ever scheduled. - **Cancelling on teardown.** Keep the handle from `requestAnimationFrame` and pass it to `cancelAnimationFrame` when the widget is destroyed, or the callback runs against detached nodes. - **A non-passive scroll listener.** Declaring `{ passive: true }` tells the browser the handler will not call `preventDefault()`, so it need not wait on it. - **Measuring inside the write phase.** Any read that sneaks in after the first write puts the second flush back. ## When one layout per frame is not achievable Some effects genuinely need to measure the result of a change — for example writing a size, then measuring how the content wrapped. That costs a second flush by definition. The honest options are to accept exactly one extra flush and do it deliberately, or to defer the follow-up measurement to the next frame so the browser's own layout pass produces the value you need. What you must not do is let that two-phase dance repeat per widget.