The previous lesson established that a widget is a cheap, immutable, throwaway description — discarded and rebuilt on every `build()` call. That fact immediately raises a question anyone who has used a UI toolkit before will ask: if the description is discarded every time, where does anything actually live between rebuilds? A running counter needs to remember its count. A running animation needs to remember its progress. A text field needs to remember what the user has typed. None of that can live on the widget itself, because the widget does not survive past one build.
The answer is a second, parallel tree that Flutter maintains alongside the widget tree: the Element tree. Elements are the long-lived objects; widgets are the short-lived descriptions elements are configured from. `StatelessWidget` and `StatefulWidget` are two different contracts for how a widget relates to this longer-lived layer — a `StatelessWidget` has nothing that needs to persist across rebuilds, while a `StatefulWidget` explicitly carries a companion `State` object that does persist, surviving rebuild after rebuild even though the widget itself is discarded and recreated each time.
Analogy🏏Cricket
🏏 Think of it like cricket: A ball-by-ball scorecard graphic shown on a broadcast is redrawn completely fresh for every single delivery — the previous graphic is gone the instant a new one is rendered. But the actual match state that graphic is drawn from — total runs, wickets, overs bowled, which batter is on strike — is tracked continuously in the scoring computer underneath, carried forward from delivery to delivery, ball after ball, never reset just because the on-screen graphic is redrawn. Just as the on-screen graphic is redrawn fresh every ball while the underlying scoring state persists underneath it, a widget is rebuilt fresh every frame while its underlying State object, if it has one, persists underneath it. Just as a scoring computer with nothing to carry forward (like a static "match sponsor" graphic) needs no persistent state at all, a StatelessWidget with nothing to carry forward needs no State object at all. This reveals why Flutter needs two different widget contracts: some UI genuinely has nothing to remember, and some genuinely does, and pretending otherwise either wastes a persistent object on nothing or loses information that needed to survive.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.