ScrollView versus FlatList for long lists

WHAT THIS TESTS Whether you understand the core difference between eager rendering and virtualization, and can pick the right component based on data size rather than habit.

A GOOD ANSWER COVERS A ScrollView renders every child as soon as it mounts and keeps them all in memory regardless of whether they are on screen. That is perfectly fine for a small, finite amount of content like a settings page or a form. A FlatList is virtualized: it renders only the items currently in the viewport plus a configurable buffer above and below, and it unmounts or recycles items as they scroll out of view. This keeps memory and render cost roughly constant even for thousands of items. The rule of thumb is to use ScrollView when the number of items is small and known, and FlatList when the list is long, scrollable beyond the screen, or driven by remote data of unknown length.

COMMON WRONG ANSWERS Claiming FlatList is always faster, even for three items, where its overhead is unnecessary. Mapping a large array inside a ScrollView because it is simpler, which mounts everything and causes startup jank and memory spikes. Believing ScrollView lazily renders its children, which it does not. Confusing horizontal versus vertical orientation with the virtualization difference.

LIKELY FOLLOW-UPS What props does FlatList add for performance tuning? How does virtualization affect measuring item layout? When would you reach for SectionList or FlashList instead?

ONE CONCRETE EXAMPLE A profile settings screen with eight rows is a natural ScrollView; everything fits and mounting all rows is cheap. A social feed pulling hundreds of posts from an API should be a FlatList; only the dozen visible posts plus a small buffer are mounted, so scrolling stays smooth and memory does not grow with feed length. Swapping the feed to a ScrollView would mount all posts at once and visibly stutter on load.