FLIP: layout animation without paying layout every frame

The problem: the destination is a layout change

Reordered lists, expanding cards, items entering a grid — the end state genuinely differs in geometry, so some layout work is unavoidable. The naive implementations animate the layout properties themselves (top, left, width, height), which means the previous lesson’s worst case multiplied by item count: every frame re-runs style, layout, and paint for every animated element and everything their geometry touches. Numbers from the Hook: layout on a 200-card column costs ~8 ms, paint ~4 ms — 12 ms of a 16.7 ms frame at 60 Hz gone before any JS, and arithmetically impossible at 120 Hz. The insight behind FLIP: browsers are excellent at transform animation, and any motion between two known rectangles can be expressed as a transform. So compute the two rectangles, and never animate geometry at all.

FLIP: First, Last, Invert, Play

First — measure every element’s rectangle before the change. Last — apply the real DOM change (React commits the reorder) and measure the new rectangles. Invert — for each element, compute the delta and apply a transform that visually moves it back to where it was: the DOM is in the final state, but the screen still shows the old one. Play — animate the transform to identity; the element glides to where it already is. In React, the seam for Last and Invert is useLayoutEffect: it runs after the DOM mutation but before paint, so the user never sees the un-inverted frame. Together these four steps mean layout runs at the endpoints only, never in the middle; skip the Invert step and the user sees a visual jump before the animation even starts.

function reorder(nextOrder) {
  // First: measure every row BEFORE React commits the new layout
  const first = new Map();
  refs.current.forEach((el, id) => first.set(id, el.getBoundingClientRect()));
  firstRects.current = first;
  setOrder(nextOrder);
}

useLayoutEffect(() => {
  const first = firstRects.current;
  if (!first) return;
  firstRects.current = null;
  // Last: new layout is in the DOM but not painted yet
  refs.current.forEach((el, id) => {
    const f = first.get(id);
    if (!f) return;                              // entered item: no First rect
    const l = el.getBoundingClientRect();        // batched reads — no writes yet
    const dx = f.left - l.left;
    const dy = f.top - l.top;
    if (dx === 0 && dy === 0) return;
    // Invert + Play: start displaced, animate to identity
    el.animate(
      [{ transform: `translate(${dx}px, ${dy}px)` }, { transform: "none" }],
      { duration: 220, easing: "cubic-bezier(0.2, 0, 0, 1)" }
    );
  });
}, [order]);

Per drop this pays layout twice — once implicitly when First reads after the previous frame, once when the Last reads force layout for the freshly committed DOM — and then every animated frame is compositor-eligible transform work. WAAPI’s el.animate is the right Play tool: it composes with the element’s other styles, handles cleanup, and exposes finished and cancel for interruption.

getBoundingClientRect and layout thrashing

getBoundingClientRect is cheap when layout is clean — it reads cached geometry. It is expensive in exactly one situation: layout is dirty (something wrote a style or mutated the DOM since the last layout), in which case the browser must run a forced synchronous layout right now to answer correctly. Interleave reads and writes in a loop and you force one layout per iteration — the Hook’s 380 ms freeze was 200 forced layouts in one frame. The discipline is batching: all reads, then all writes. FLIP written correctly is naturally batched — First is a read pass, the commit is one write burst, Last is a read pass, Invert is a write pass. Break that order (read one card, transform it, read the next) and the transforms themselves are fine but the interleaving resurrects the thrash.

Framer Motion layoutId: FLIP with the measuring automated

Framer Motion’s layout prop and layoutId are not a different technology — they are FLIP with the bookkeeping done for you. On every render the library measures the bounding boxes of layout-tracked elements, compares them to the previous measurements, and if a box moved or resized, applies the inverted delta as a transform and plays it to identity. layoutId extends the same trick across components: when a new element mounts with the layoutId of one that just unmounted, the library uses the old element’s rect as First and the new element’s rect as Last — a shared-element transition built from the same getBoundingClientRect plus transform you can hand-write. Knowing this demystifies the failure modes: layout animations cost a measurement pass per render (which is why you scope layout to what moves, not the whole tree), and anything FLIP cannot fake — text reflow, certain paint effects — Framer Motion cannot fake either.

Scale distortion and the counter-scale correction

Moving elements is the easy case — translate distorts nothing. Resizing via FLIP means animating scale, and scale multiplies everything inside: an expanding card animating from 320 px to 640 px wide starts at scaleX(0.5) un-inverted… inverted to appear original-size, but its children — text, avatars, borders — are visually squashed or stretched mid-flight. The correction is counter-scaling children: apply the inverse factor (1/parentScale, recomputed per frame because the parent’s scale changes per frame) to a child wrapper. Framer Motion does this automatically for nested layout elements; hand-rolled FLIP must drive both animations from one clock. Border-radius has the same disease — a 12 px radius under scaleX(2) renders as a 24 px-by-12 px ellipse — which is why production FLIP either animates radius separately or accepts the brief distortion on fast (under ~250 ms) animations.

When FLIP breaks

• Text reflow. If the real width changes, text re-wraps at the destination width. FLIP shows scaled — stretched — text during flight, then text is suddenly correct at the end; there is no transform that re-wraps lines. Options: fix the text container’s width and animate only the box; crossfade between two snapshots; keep the animation short enough that stretching reads as motion blur.
• Entering and exiting items. A list item that just mounted has no First rect (nothing to invert — give it a separate enter animation); an item that unmounted cannot be measured for Last (it is gone — exit animations need the element kept alive, which is what AnimatePresence does).
• Stale measurement. First rects measured, then something else moves the page (an image loads, a banner collapses) before Last — the deltas are wrong and items glide from the wrong origin. Measure as late as possible, immediately before the commit.

The numbers: 200-item reorder, naive vs FLIP

Naive tween on top, 200 items, 60 Hz: every frame pays style recalc (~1.5 ms) + layout (~8 ms) + paint (~4 ms) ≈ 13.5 ms — over budget with zero JS, ~22 fps observed, and at 120 Hz not even theoretically possible. FLIP on the same list: the drop frame pays two layout passes (First reads ride the clean layout from the previous frame; Last reads force one layout ≈ 8 ms) plus 200 el.animate calls (~1 ms) — one long-ish frame of ~10–15 ms once, then every animated frame is transform-only: microseconds of main-thread cost, compositor does the rest, flat 60 fps on the Hook’s laptop. The trade is honest: FLIP buys per-frame freedom by paying a bounded, one-time measurement cost — and that cost scales with item count, which is why Framer Motion scopes measurement to layout-tagged elements rather than the whole tree.