FlashList

FlashList 7,238 (github.com/Shopify/flash-list (https://github.com/Shopify/flash-list 7,238 ), MIT, about 7.2k stars) takes FlatList's props but works differently: it recycles. Rows that scroll off are not unmounted; their components are re-rendered with new items and moved to the other end. Version 2, released in July 2025, was rebuilt for the New Architecture in pure JavaScript and no longer needs the size estimates version 1 required. npx expo install @shopify/flash-list installed 2.0.2, the version Expo SDK 57 6,418 pins (npm 2,036 's latest is 2.3.2).

A benchmark screen renders the same 1,000 BookRows in each container. Its Row wrapper counts renders on every call and mounts in a useEffect, and a requestAnimationFrame loop counts the frames the JavaScript thread kept up with. After six fast flings in each, this debug build logged:

 LOG  FlatList: first commit after 951 ms with 10 rows mounted
 LOG  FlatList: 146 mounts, 156 renders, 4.2 JS fps over 28.0 s
 LOG  FlashList: first commit after 205 ms with 0 rows mounted
 LOG  FlashList: 15 mounts, 77 renders, 29.0 JS fps over 27.0 s
 LOG  ScrollView: first commit after 16857 ms with 1000 rows mounted
 LOG  ScrollView: 1000 mounts, 1000 renders, 5.7 JS fps over 38.4 s

FlashList mounted 15 rows and reused them; FlatList kept mounting new ones, and during the flings it printed "You have a large list that is slow to update". ScrollView spent 17 seconds mounting everything. Treat the fps figures as relative: a debug build on a shared emulator is far slower than a release build on a phone, which is where FlashList's documentation says to measure. The two differ in approach more than in API:

Swap it in by changing the component name; drop FlatList-only props such as getItemLayout, columnWrapperStyle and windowSize, and avoid key props inside rows, which defeat recycling.