Springs, and what you give up for them

Duration becomes an output

A bezier tween is defined by where it starts, where it ends, and how long it takes. A spring is defined by physics, and the duration falls out of the physics. You do not set it.

Three numbers control a spring simulation:

• Stiffness: how hard it pulls towards the target. Higher is faster and snappier.
• Damping: how much energy is removed each step. Higher settles sooner with less wobble.
• Mass: inertia. Higher is slower to start and slower to stop.

The relationship that matters is the damping ratio: damping divided by twice the square root of stiffness times mass.

• Ratio below 1: underdamped. It overshoots and oscillates. This is what most people want and what “springy” means.
• Ratio exactly 1: critically damped. It arrives as fast as possible with no overshoot at all.
• Ratio above 1: overdamped. It creeps in and never overshoots. Usually feels sluggish.

A useful starting set for interface work: stiffness 200, damping 20, mass 1. That gives a ratio of about 0.7, a small single overshoot, and a settle in roughly half a second. Drop damping to 12 and it wobbles three times. Raise it to 28 and the overshoot disappears.

The real reason frameworks use springs

It is not that springs look nicer. It is that they can be interrupted.

Consider a sheet being dragged up, released halfway, and grabbed again before it finishes. A keyframed tween has a fixed start value, a fixed end value, and a clock. To redirect it you must cancel it and start a new one, and the new one starts from zero velocity, so the sheet momentarily stops dead in the user’s hand. Everybody has felt this and blamed the phone.

A spring carries velocity as state. Change the target mid-flight and the simulation continues from wherever it is, at whatever speed it had. The motion stays continuous because it never restarted. This is why SwiftUI, Framer Motion, React Spring and the Android motion libraries all default to springs for gesture-driven work.

Where a spring is the wrong choice

Overshoot means going past the value. Sometimes the value means something.

• Progress indicators. A bar that springs to 100% visibly passes 100%. You have just told the user the download is 107% done.
• Anything reading a real quantity: a gauge, a counter, a temperature. Overshoot is a false reading held for 200ms.
• Motion that must land on a beat or a word. You cannot specify a spring’s duration, so you cannot make it finish at frame 74. For sound sync, use keyframes.
• Anything rendered to a video file for a fixed-length edit. Same reason. Bake the spring to keyframes first if you need both.

There is also a subtler one: springs make everything feel like the same product. When every element in an interface uses the house spring, motion stops carrying information because nothing is distinguishable from anything else.

Doing it without a framework

CSS gained the linear() easing function, which takes a list of sampled progress values. A spring is just a function of time, so you can sample it and paste the result:

.sheet {
  transition: transform 0.6s linear(
    0, 0.14, 0.42, 0.72, 0.94, 1.06, 1.09, 1.06, 1.02, 1, 1
  );
}

Those eleven numbers are a spring evaluated at eleven points in time. You can see the overshoot in the data: it passes 1 at the sixth sample, peaks at 1.09, and comes back. Any spring calculator will generate the list, and the result runs on the compositor with no JavaScript.

In Blender, add a Damped Track or bake the physics: animate the target, run the simulation, then convert to keyframes so the curve becomes editable. Glaxnimate has no spring, so you approximate with three keyframes (target, overshoot, settle) which is the bezier method from the previous lesson.

The limitation

A spring simulation is deterministic but not predictable in the way a designer needs. “How long does it take?” has no clean answer, because mathematically it never fully arrives: implementations stop when the displacement and velocity both fall under a threshold. Two libraries with the same stiffness and damping can settle at visibly different times because they chose different thresholds and different integration step sizes.

So if you specify “stiffness 200, damping 20” to a developer using a different library than the one you prototyped in, you have specified less than you think. The thing to hand over is the feel plus the numbers plus a reference recording, and a willingness to tune once it is running on the real device.