We’ve lost the Tech

Claude Code’s terminal UI is being treated like a 60 fps rendering problem, and that choice is framed as a costly mismatch between what a terminal needs and what a browser-style UI stack demands. The core claim is that the interface behaves more like a list of mostly static text with occasional updates—user input, a “throbbing” activity indicator, and streamed model output—so there’s no real reason to run a constant frame loop. Yet the system reportedly builds a React-based scene graph every frame, lays out elements, rasterizes in 2D, diffs against the previous screen, and then converts the diff into ANSI escape sequences for cursor movement, coloring, and clearing.

The transcript breaks down why that pipeline is hard to justify. A terminal “pixel” is effectively each character cell, and the typical Claude Code layout is described as roughly 30 by 120 character cells (about 2,400 cells). In that world, the expensive part shouldn’t be raw rendering speed; the expensive part is doing React’s full UI lifecycle at a rate that implies constant change. The speaker argues that input and streamed output arrive far slower than 60 updates per second, and the throbbing indicator only needs to animate at a modest cadence. When nothing changes, a well-designed renderer should do nothing—no React reconciliation, no layout, no rasterization, no diffing, no ANSI regeneration.

Instead, the transcript suggests the project is “tunneling through a mountain”: legacy architectural decisions that make a terminal UI look like a browser UI. React is described as optimized for complex, interactive web interfaces with frequent state changes, not for a terminal that can be rendered in immediate mode. The speaker’s counter-model is straightforward: store the terminal state as a list of elements or changes, redraw only when events occur, and avoid a scene graph that must be diffed every frame. In games terms, the terminal UI should behave like immediate-mode rendering rather than a continuously updated scene graph.

To support the intuition that rendering itself isn’t the bottleneck, the transcript includes a personal benchmark: drawing thousands of character-cell boxes at extremely high rates in a GPU-accelerated terminal (Ghostty), and separately simulating scrollback history with a throbbing indicator. The results are presented as evidence that modern terminal rendering can be fast enough that 60 fps should not be the limiting factor. If the system still misses its 16 ms frame budget, the transcript points the finger at the React-driven pipeline and coupling between data and renderer.

The broader engineering-management critique is that teams can get trapped in tackling immediate technical challenges while failing to revisit the original decision that created the constraint. The transcript also argues that leadership’s fear-mongering about the future of engineering doesn’t match the reality of the company’s own technical debt: legacy choices can dominate outcomes regardless of whether code is written by humans or generated by LLMs. The takeaway is less about blaming a language and more about insisting on the right architecture for the job—then verifying that the implementation actually follows through with care.