Animated API versus Reanimated architecture

WHAT THIS TESTS Whether you understand React Native's threading model and why animation jank happens, not just which API has nicer syntax.

A GOOD ANSWER COVERS The built-in Animated API runs on the JS thread by default. With useNativeDriver true it serializes a declarative description of the animation to the native side, where transform and opacity can be driven without further JS involvement. The limitation is that the native driver supports only a fixed set of non-layout properties, and anything reactive, such as gestures or per-frame computed values, must still travel across the asynchronous bridge, so a busy JS thread causes dropped frames. Reanimated takes a different approach: it lets you write worklets, small JavaScript functions that are extracted and executed on a separate UI thread runtime. Shared values live in memory accessible to both threads, and style updates derived from them happen synchronously each frame on the UI thread, so animations and gestures stay smooth even when JS is blocked.

COMMON WRONG ANSWERS Saying the native driver works for layout properties like width or height. Claiming Reanimated removes the bridge for everything in the app. Treating the two libraries as syntactic equivalents. Ignoring that gesture-driven interpolation is exactly where the bridge hurts the legacy API.

LIKELY FOLLOW-UPS What is a worklet, what is a shared value, when is the legacy Animated API still fine, and how does the new architecture and JSI change this picture.

ONE CONCRETE EXAMPLE A draggable sheet that follows the finger and snaps on release: with Animated plus PanResponder, each touch event crosses the bridge to JS and back, so a slow JS thread makes the sheet lag the finger. With Reanimated, the gesture handler and the position math run as worklets on the UI thread, so the sheet tracks the finger at 60 frames per second regardless of JS work.