Animations with Reanimated

An animation driven entirely from JavaScript — updating a value on every frame and pushing it across the bridge to the native side to redraw — is racing against everything else the JS thread is doing that frame: state updates, event handlers, list rendering. The moment the JS thread does real work mid-animation, the animation stutters, because there was never a guarantee it would get to run before the next frame was due. This is the exact problem Reanimated exists to solve: it lets animation logic run as a worklet, a small function that executes directly on the UI thread, independent of whatever the JS thread is doing, so a gesture-driven drag or a spring animation keeps hitting its frame deadline even while JavaScript is busy elsewhere.

Reanimated is not simply "a faster Animated API" — it is a fundamentally different execution model, and the model is the part that has to be understood correctly, because misunderstanding it produces animations that appear to work in simple cases and then fail confusingly the moment a worklet tries to touch something it should not. A shared value updated on the UI thread that a component naively tries to read as a plain JavaScript number, or a worklet that calls an ordinary JavaScript function it was never told is safe to call across the thread boundary, are the two most common ways this goes wrong.

This is an exercise lesson: every code block below is something to actually run and modify, not just read. Build the pieces in order — a shared value driving a style, a worklet responding to a gesture, and a spring-based transition — and by the end you should be able to reason about which thread any given line of animation code actually executes on, which is the single most useful diagnostic question in Reanimated debugging.

Analogy🏏Cricket

🏏 Think of it like cricket: A fielding side's slip cordon does not wait for a shout from the dressing room before reacting to a nick off the bat — the slip fielders react in real time, on the field, because the decision to dive or not has to happen within a fraction of a second no dressing-room communication channel could keep up with. The captain sets the field position and the general strategy beforehand, from the dressing room, but the actual split-second reaction to the ball happens entirely on the field, independent of anything the dressing room is doing in that instant. Just as the slip cordon reacts on the field in real time rather than waiting on a signal from the dressing room, a Reanimated worklet reacts to a gesture on the UI thread in real time rather than waiting on a round trip to the JavaScript thread. Just as the captain's dressing-room strategy still shapes what the fielders do without being in the loop for every single reaction, JavaScript still configures and triggers animations without being on the critical path for every single frame. The insight is that some decisions genuinely need to happen at the point of contact, with no round trip to a slower, busier coordination layer, and building that reaction directly into the place where speed actually matters is what keeps it reliable under pressure.