Live Vote Bar Race — Free FLIP-Animated Ranking Snippet

The "bar chart race" format — a set of labeled horizontal bars that grow, shrink, and swap vertical positions as their underlying numbers change over time — has become one of the most recognizable data-visualization formats on social media, used constantly for election results, sports standings, and trending topics. This snippet builds a live, interactive version: five candidates with simulated vote counts that update on a timer, bars that resize smoothly, rows that physically glide past each other when their rank changes, and a small crown animation whenever a new leader takes first place.

Why naive re-sorting causes a visual "pop"

The obvious way to reorder a list of DOM rows by rank is to sort the underlying data and re-insert the elements in the new order — container.appendChild(row) for each row in rank order. The problem is that the browser has no concept of "this row used to be third and is now first" once you do that; it simply computes a new layout and paints it. The result is every reordered row instantly jumping to its new position with zero visible motion — a jarring pop that makes it hard to follow which item moved where, exactly the failure mode a bar-chart race must avoid to be legible.

FLIP: First, Last, Invert, Play

The fix is the FLIP technique. First: before touching the DOM order, reorderWithFlip() records every row's current top position with getBoundingClientRect(). Last: the rows are then actually re-inserted into the container in their new sorted order — a real DOM mutation, causing an instant (invisible, un-animated) jump to the new layout. Invert: for each row, the delta between its old top and its new top is computed, and that delta is applied as a transform: translateY(...) — which visually cancels the jump out, making the row *appear* to still be sitting in its old position even though it has already moved in the DOM. Play: a CSS transition is enabled and the transform is reset to translateY(0), so the browser animates from the inverted (old-looking) position to the true (new) position — which the eye reads as the row smoothly gliding to its new rank, exactly the effect a bar race needs.

The forced-reflow step is not optional

Between setting the inverted transform and clearing it, the code calls row.getBoundingClientRect() again purely to force the browser to compute layout synchronously. Without this, both style writes can get batched into a single paint and the transition has no starting frame to animate from — the row would just silently snap to its final position. This one-line detail is the most common way a from-scratch FLIP implementation silently stops animating.

Why bar width still uses a plain CSS transition, not FLIP

Only the *reordering* (vertical position) needs FLIP, because a width change on a single element does not have the "the browser threw away my old position" problem that reordering has — a straightforward transition: width 0.5s on .vbr-fill already animates smoothly between two known widths on the same element. FLIP specifically solves the reordering problem, not general-purpose resizing, so this snippet uses the right tool for each of its two moving parts rather than over-engineering the whole thing through FLIP.

Deriving the crown from the same sorted data, not a separate check

The trophy/crown only appears on the current ranked[0] and is shown or hidden via a plain classList.toggle('show', c.id === leader.id) recomputed every tick — it never has its own independent state. A small pop animation (a scale-and-lift transform, hand-triggered rather than declared as a @keyframes loop) only fires when leader.id !== lastLeaderId, so the celebratory bounce plays exactly once per actual leadership change, not on every tick where the same candidate happens to still be winning.

Simulated data on a timer, structured for a real feed

tickVotes() randomly nudges each candidate's vote count and is called from a plain setInterval; in a production version you would replace the random nudge with data pulled from a WebSocket or polling endpoint and call the same reorderWithFlip() + updateBars() pair whenever new numbers arrive — the animation layer is fully decoupled from where the numbers come from.