Why react-native-gesture-handler Replaces the Responder System

WHAT THIS TESTS Whether you understand that the built-in gesture system is JS-thread bound and why moving recognition to native matters.

A GOOD ANSWER COVERS React Native's built-in Gesture Responder System runs touch handling and gesture negotiation on the JavaScript thread. When the JS thread is busy, for example during a heavy render or list update, touch events queue up or arrive late, so gestures stutter, feel laggy, or are dropped entirely. The system also handles composing and arbitrating between competing gestures awkwardly and does not integrate cleanly with native scroll containers. react-native-gesture-handler addresses this by performing gesture recognition on the native UI thread using each platform's native touch system. Because recognition no longer depends on the JS thread, gestures stay smooth and responsive even when JavaScript is blocked, latency is lower, and the library integrates with native ScrollView and other native components, supports declarative composition of simultaneous and exclusive gestures, and pairs with Reanimated to drive animations entirely off the JS thread.

COMMON WRONG ANSWERS Saying the built-in system already runs on the native thread; it does not, which is the core problem. Claiming gesture-handler is only nicer API ergonomics rather than a performance and reliability change. Forgetting the dropped-event behavior under JS load.

LIKELY FOLLOW-UPS How gesture-handler pairs with Reanimated worklets to keep animations off the JS thread. How simultaneous versus exclusive gesture composition works. Why native scroll integration was hard with the old system.

ONE CONCRETE EXAMPLE A swipe-to-dismiss row in a busy list using the built-in system stutters whenever the list re-renders because touches wait on the JS thread. Rewritten with gesture-handler, recognition happens natively, so the swipe stays smooth even while JavaScript is busy updating data.