The Web Animations API: animate, finish, keep the result
el.animate() uses the same engine as CSS animations, so a transform animation can run on the compositor too. finished is a promise, more reliable than events. commitStyles() plus cancel() keeps the end state without leaving a filling animation alive.
Smooth animation means producing a new frame every 16ms or so; animating transform and opacity lets the browser skip layout and paint and move ready-made layers on the compositor, will-change hints at this ahead of time, and prefers-reduced-motion lets you tone motion down for people it makes ill.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Rewrite this animation so it doesn't trigger layout: @keyframes drop { from { top: -50px; } to { top: 0; } } on an absolutely positioned toast.
Make a .spinner that spins forever, but for reduced-motion users stops spinning and pulses its opacity slowly instead.
Write JavaScript that slides a .panel 200px to the right with the Web Animations API (0.3s), but makes the change instantly when the user prefers reduced motion. Log "moved" when it's done.
Explain it without notes
Why are transform and opacity the preferred properties to animate?
What is the compositor thread, and why does it keep some animations smooth while JavaScript is busy?
What does will-change do, and what are the risks of overusing it?
What is layout thrashing and how do you avoid it?
How should a site respond to prefers-reduced-motion: reduce?
Preview
Console
Nothing logged yet.Expected console output
will-change: transform
playState: finished
transform: matrix(1, 0, 0, 1, 120, 0)
inline style: translateX(120px)