FlatList and virtualization: why ScrollView doesn't scale
Data Structures & Algorithms' own domain taught Big-O intuition as a way to reason about cost growing with input size. FlatList's entire reason for existing is a direct, concrete application of that same intuition to mobile rendering — and it's the single most common real performance fix a React Native app needs.
Intermediate
2 min read
The problem, concretely: ScrollView renders everything, immediately
A ScrollView wrapping 5,000 chat messages renders all 5,000MessageBubble components immediately, whether or not they're anywhere near the visible screen — every one of them occupies real memory, and every one of them was actually laid out and drawn by the native rendering layer, long before a user ever scrolls far enough to see most of them. This is exactly the kind of cost-growing-with-input-size problem Data Structures & Algorithms' own Big-O lesson trained you to recognize — rendering cost here scales linearly with total list length, not with what's actually visible.
FlatList: render only what's near the visible screen
FlatList only renders items near the currently visible viewport — as a user scrolls, items that move far off-screen are actually removed from memory and replaced by newly-visible ones being rendered fresh, a technique called virtualization (windowing). Rendering cost now scales with viewport size, not total list length — a 5,000-item list and a 50-item list cost roughly the same to render at any given moment, which is the entire point.
keyExtractor: the same reconciliation concept React's own domain already taught
React's own keys-and-reconciliation lesson already explained why a stable, unique key per list item matters — FlatList's keyExtractor is that exact same concept, applied specifically here because virtualization makes it matter even more: items are constantly being mounted and unmounted as they scroll in and out of the rendered window, and a missing or unstable key causes React to lose track of which on-screen item corresponds to which data item, producing the same "wrong item re-renders, or state jumps to the wrong row" bugs React's own domain already covered, just triggered far more frequently here.
When ScrollView is still the right choice
A short, genuinely bounded list — a settings screen with eight fixed options, a form with a known, small number of fields — gains nothing from virtualization's added complexity (and actually loses a little, since FlatList has real overhead in managing the virtualization window itself). The actual decision criterion: is this list's length bounded and small, or does it scale with real, potentially large data (messages, a product catalog, a social feed)? ScrollView for the former, FlatList (or its sibling SectionList, for grouped data) for the latter.