⚡ FlashList Internals Explained

 

Why It’s Faster Than FlatList (And When You Should Use It)

If you’ve ever replaced FlatList with FlashList and thought:

“Why does this feel magically smoother?”

The answer is not magic.
It’s architecture, predictability, and aggressive recycling.

Let’s open the hood and see what actually happens.

---

🧠 The Core Problem FlashList Solves

FlatList tries to answer this question on every scroll:

“Which items should I render now?”

But it often doesn’t know:

• Exact item size

• Layout cost in advance

• How expensive rendering is

So FlatList plays safe:

• Renders extra items

• Keeps more views alive

• Asks JS thread more often

FlashList flips this model.

---

🧩 The FlashList Mental Model (Very Important)

FlashList is a recycler first, renderer second

Instead of:

• Creating views → destroying views → recreating views

FlashList:

• Creates a small pool of views

• Recycles them aggressively

• Rebinds data instead of re-rendering trees

This is the same idea used by:

• Android RecyclerView

• iOS UITableView

---

🔄 What Happens Internally During Scroll

Let’s walk through a scroll frame.

1️⃣ Native thread handles scroll

• Touch + momentum handled natively

• No JS involvement yet

2️⃣ FlashList calculates visible window

• Uses estimated item size

• Predicts how many items fit on screen

3️⃣ Recycler kicks in

• Finds reusable views from pool

• No new view creation

4️⃣ JS thread only updates data bindings

• item prop changes

• Same view instance reused

5️⃣ Native updates layout

• Minimal layout work

• No expensive mount/unmount cycles

📌 Key difference
FlatList asks: “Should I create or destroy?”
FlashList asks: “Which existing view can I reuse?”

---

🧵 Why FlashList Is Easier on the JS Thread

Let’s compare JS work.

FlatList (simplified)

scroll →
  renderItem →
    create elements →
      diff →
        mount/unmount →
          native updates

FlashList (simplified)

scroll →
  reuse view →
    update props →
      minimal diff →
        native updates

Less JS work = fewer frame drops.

---

🧠 The Secret Sauce: estimatedItemSize

This single prop is critical.

<FlashList
  data={data}
  renderItem={renderItem}
  estimatedItemSize={80}
/>

Why it matters

• FlashList pre-calculates layout

• Skips expensive measurements

• Avoids layout thrashing

Without it:

• FlashList still works

• But you lose most of the performance gains

📌 Think of it as:

“Give me a close guess, I’ll optimize the rest.”

---

🧩 View Recycling in Practice (Pseudo Code)

Internally, FlashList behaves like this:

const viewPool = [];

function getView() {
  return viewPool.pop() || createNewView();
}

function recycleView(view) {
  viewPool.push(view);
}

function onItemVisible(item) {
  const view = getView();
  bindData(view, item);
  attachToScreen(view);
}

function onItemHidden(view) {
  detachFromScreen(view);
  recycleView(view);
}

Notice what’s missing ❌

• No destruction

• No recreation

• No repeated mounting

---

⚠️ Why FlashList Feels Faster on Android

Android is more sensitive to:

• View creation cost

• Layout passes

• Bitmap decoding

FlashList:

• Reduces view churn

• Minimizes layout recalculations

• Keeps native memory stable

That’s why Android gains are often more dramatic.

---

🧱 Old vs New Architecture Context

Old Architecture

• FlatList JS delays amplified

• Recycler benefits limited by bridge

New Architecture (Fabric + JSI)

• Faster commits

• Better scheduling

• FlashList shines even more

📌 FlashList does not depend on the new architecture
—but benefits heavily from it.

---

✅ When You SHOULD Use FlashList

FlashList is ideal when:

• Lists are long

• Items are complex

• Scroll performance matters

• You don’t know item height exactly

• FlatList tuning still isn’t enough

Typical examples:

• Feeds

• Chat lists

• Activity timelines

• Search results

---

❌ When FlashList Is NOT Ideal

Avoid FlashList when:

• List is very small (≤ 10 items)

• Layout is extremely dynamic

• Item size varies wildly and unpredictably

• You can’t provide a reasonable estimate

FlatList is simpler and sufficient in those cases.

---

⚖️ FlashList vs FlatList (Quick Comparison)

Aspect	FlatList	FlashList
Default behavior	Safe	Aggressive
View recycling	Limited	Heavy
JS thread usage	Higher	Lower
Setup complexity	Low	Medium
Large lists	❌	✅
Android performance	⚠️	🚀

---

🛠️ Migration Is Easy (Almost Drop-In)

import { FlashList } from "@shopify/flash-list";

<FlashList
  data={data}
  renderItem={renderItem}
  keyExtractor={item => item.id}
  estimatedItemSize={80}
/>

Most FlatList props work the same.

---

💡 Final Mental Model

FlatList tries to be correct first.
FlashList tries to be fast first.

Neither is “better” universally —
they are optimized for different problems.

If your app scrolls:

• A lot

• With many items

• On mid-range devices

FlashList is often the right tool.