Flutter lied. Not everything is a widget.
I love explaining tech concepts, that seem like a nightmare!
Flutter’s doc tells us: “Everything is a widget.” It’s catchy. It’s memorable…but not the whole story.
If widgets did all the work, your app would be incredibly slow. Why? Because widgets are destroyed and recreated constantly. If you had to repaint the entire screen every time a tiny variable changed, your phone would turn into a space heater.
So, what’s really happening under the hood?
The Illusion
When you write:
// You write this (Widget Tree):
Container(
color: Colors.blue,
child: Text("Hello"),
)
// Flutter creates this Element:
ContainerElement
└─ TextElement (stays alive across rebuilds!)
// Which tells the RenderObject:
RenderBox
└─ RenderParagraph (actually draws pixels)
// When color changes, only the RenderBox repaints.
// Element and Text stay intact!
It feels like:
Containeris drawing a boxTextis drawing letters
But that’s not what happens.
Widgets are just configuration objects.
They’re blueprints.
Every time build() runs, new widget objects are created.
The old ones are thrown away.
If widgets were responsible for rendering, your UI would constantly reset.
But it doesn’t.
So something else must be doing the real work.
The Three Trees
Flutter doesn’t run on one tree; it’s a triple-threat operation. Think of it like a theater production:
1. The Widget Tree (The Script)
Role: Description.
Vibe: "I think the character should wear a blue hat."
The Pro Detail: Widgets are Immutable. They are frozen in time. If you want to change a color, you can’t edit the old widget; you have to "print" a brand-new one.
2. The Element Tree (The Actors)
Role: Lifecycle Management.
Vibe: "I am the actor. I handle the casting call (
createElement)."The Pro Detail: This tree is the "glue." It links the immutable script to the living stage. It's the only tree that truly understands State.
3. The Render Tree (The Stage Crew)
Role: Math & Art.
Vibe: "We do the heavy lifting."
The Pro Detail: They work in two phases:
Layout: Measuring the stage (How big is this button?).
Painting: Drawing the pixels (What color is it?). By splitting these phases, Flutter can skip layout if only paint properties changed. Smart, right?
Why This Matters (The "Pro" Perspective)
Understanding the "Three Trees" explains the "Whys" of Flutter:
Why Rebuilds are Cheap: Because you’re just swapping "scripts" (Widgets), not firing the "actors" (Elements) or tearing down the "stage" (RenderObjects).
Why State persists: Because the Element stays alive even when the Widget is replaced.
Why Keys matter: Keys help the Element (the Actor) identify which Widget (the Script) it should be following when things move around.
When Does This Actually Matter?
You can ignore this 90% of the time. But you NEED to know it when:
❌ Your app lags during animations → You're rebuilding RenderObjects unnecessarily
❌ State mysteriously resets during rebuilds → You're not using keys, so Elements are confused
❌ You want custom painting or gestures → You'll work directly with RenderObjects
✅ Otherwise? Just think "everything is a widget" and ship.
🎯 The Mental Model Upgrade
Flutter didn’t really lie; it simplified. For 90% of your work, thinking "everything is a widget" is fine.
But when you want to understand performance, keys, and how state actually works, you have to look deeper. The real power of Flutter isn't in the blueprints—it's in the way it manages the workers beneath them.
One Sentence to Remember:
Widgets are the "What," Elements are the "Who," and RenderObjects are the "How."The Truth
You have to go deeper.
Because not everything is a widget.
And the real magic lives beneath them.
Up next in the line up…
The 16ms Miracle: Script, Actor, and Stage in the
setState()Dance
