CellState：React 不是终端 UI 的瓶颈，输出管道才是。
Anthropic 重写了 Claude Code 的终端渲染器，发现问题并不在于 React，而在于 Ink 的逐行重写。我将他们的方法构建成了一个独立的库。
CellState 使用了一个自定义的 React 协调器，直接渲染到单元格网格，并在单元格级别逐帧进行差异比较。由于它在内联模式下运行，而不是在替代屏幕上，因此保留了原生终端的行为（如滚动、文本选择、Cmd+F）。
React 的协调器只处理发生变化的子树，而单元格差异只覆盖视口，而不是整个滚动历史。
在 250 条消息（33KB 内容）时，单个单元格更新无论内容大小如何，都只向终端写入 34 字节。相同的更改，Ink 则写入 41,955 字节。完整的渲染管道（协调、布局、光栅化、单元格差异）耗时 2.54 毫秒，而 Ink 则为 36.93 毫秒。
基准测试和方法论： https://github.com/nathan-cannon/tui-benchmarks
https://github.com/nathan-cannon/cellstate
查看原文
Anthropic rewrote Claude Code's terminal renderer and found that React wasn't the problem. Ink's line-level rewriting was. I built their approach into a standalone library.<p>CellState uses a custom React reconciler that renders directly to a cell grid and diffs frame-by-frame at the cell level. You keep native terminal behavior (scrolling, text selection, Cmd+F) because it runs inline instead of alternate screen.<p>React's reconciler only touches the subtree that changed, and the cell diff only covers the viewport, not the full scrollback.<p>At 250 messages (33KB of content), a single cell update writes 34 bytes to the terminal regardless of content size. Ink writes 41,955 bytes for the same change. The full rendering pipeline (reconciliation, layout, rasterize, cell diff) takes 2.54ms vs Ink's 36.93ms.<p>Benchmarks and methodology: https://github.com/nathan-cannon/tui-benchmarks<p>https://github.com/nathan-cannon/cellstate