ThePrimeagen has chosen a fairly aggressive way to manage his game's interface: rebuild most of it every frame.

For a web page, that sentence sounds mildly threatening. For the small game UI he is writing in Odin, he finds the model easier to reason about than the retained-mode approach he used in an earlier version.

The video does not prove one UI architecture has won forever. It shows something more transferable: move complexity to the place where the person writing the code can actually understand it.

Retain the interface or calculate it again

Around 1:28, ThePrimeagen starts with the familiar DOM model.

In retained-mode UI, elements persist inside a structure. You create an object, keep its identity and later react to events such as hover, click, focus or state changes.

His current system takes the other direction. Around 1:45, he introduces an immediate-mode UI. Every frame, the program looks at current state and builds the required elements again.

For this game, he expects roughly 50 to 100 active UI elements at most. In that specific context, recalculating the small tree each frame does not concern him as a performance cost.

That estimate belongs to his project. It is not a universal license to rebuild a giant application sixty times a second and declare architecture solved.

Layout begins at the leaves

At 2:52, he says he studied a video explaining Clay's layout algorithm and adapted part of its approach.

His requirements are deliberately narrow: boxes, horizontal or vertical alignment, centering, text and sprites.

Sizing walks down to the leaves of the tree. A leaf can have fixed dimensions, derive its size from text or use a sprite's dimensions. Once those values are known, parent boxes can calculate their own size from their children, padding and gaps.

Positioning comes afterward.

Around 5:47, the process becomes almost mechanical. Once child sizes are known, their positions can be accumulated one after another. Centering on the secondary axis means comparing parent and child dimensions.

None of these rules is particularly mysterious alone. The work is choosing few enough rules that their combinations remain predictable.

The mouse breaks the clean story

Around 7:06, the interesting problem appears.

Imagine an element grows when the mouse hovers over it.

To know whether the pointer is inside the element, the program needs its position and size. But its new size depends on whether the pointer is inside it. The interface being built does not fully exist yet.

A small chicken-and-egg problem, now with more rectangles.

ThePrimeagen's solution is to keep the previous layout root. At the beginning of the next frame, he tests the current mouse position against geometry from the previous one. That produces hover, drag and enter/exit state that can be used while constructing the new frame.

He deliberately accepts information that is one frame old in exchange for a simpler model.

That is a very game-development kind of compromise. The previous frame is rarely far away.

Less persistent event state, more explicit calculation

Around 9:35, he explains why the approach appeals to him.

In his earlier retained UI, hover behavior required state to survive across event handlers. One event marks entry, another marks exit, and the program has to remember what happened between them.

In the immediate system, a component can ask while being constructed: am I hovered right now? If so, it directly chooses its size or animation for this frame.

The complexity has not vanished. It has moved into layout calculation, previous-frame geometry and continuous reconstruction.

For him, that makes the code more local and readable.

The revealing part is when AI could write the ugly code anyway

Around 11:19, ThePrimeagen looks at a more verbose component API and makes a useful observation.

An agent could easily generate the repetitive parameter objects. That is not the problem. He still has to read the resulting code afterward.

So he starts building a smaller construction API that feels better to him, even though AI could happily produce the version he dislikes.

That constraint matters in a world where generation keeps reducing the cost of typing.

If twenty repetitive lines become almost free to produce, they can still charge rent every time a human reads, debugs or changes them.

Code aesthetics do not disappear because a machine can type the code.

Architecture can be chosen for its mental model

ThePrimeagen's system is young. It is his first immediate-mode UI, inside a game where the element count is intentionally small. He is already finding tradeoffs and does not present it as a general DOM replacement.

That is exactly why the process is useful.

It does not show a finished abstraction. It shows somebody reducing a problem until he can write the rules himself, then discovering where those rules begin to resist.

The result is more than an interface that aligns cards correctly.

It is code whose author can still explain, frame by frame, why every rectangle ended up where it is.