Rust, Ropes, and Dirty Regions: Notes From Building a Terminal UI Engine

Terminal UI work looks simple from outside. It is just text in a terminal, right?

Then you try to build a real engine and the details arrive quickly: layout, focus, keyboard input, cursor state, text editing, animation, terminal resize, syntax highlighting, and rendering without making the screen flicker.

That is why I like this space. It looks small, but the engineering is deep.

Why Rust for the engine

I like TypeScript for product code and APIs. But for a terminal UI rendering core, Rust makes sense.

The engine has to do many low-level things repeatedly:

• Store a tree of UI nodes
• Compute layout
• Render into a framebuffer
• Diff the previous frame with the next frame
• Track dirty regions
• Edit large text buffers
• Avoid unnecessary allocations

Rust gives control without giving up safety. That matters when the engine is doing this work many times per second.

Framebuffer first

The important mental model is: do not print UI directly. Render into a framebuffer first.

#[derive(Clone, PartialEq)]
struct Cell {
    ch: char,
    fg: Color,
    bg: Color,
    bold: bool,
}

struct Frame {
    width: usize,
    height: usize,
    cells: Vec<Cell>,
}

The frame is the truth. Every widget writes cells into it. Then the renderer compares this frame with the previous frame and only writes the changed parts to the terminal.

That is where dirty-region rendering comes in.

Dirty regions are the difference

If a clock changes in the top-right corner, the engine should not repaint the whole screen. It should repaint the cells that changed.

That sounds obvious, but many simple terminal apps do the full redraw because it is easier.

For small apps, full redraw is fine. For complex terminal apps with scrolling, syntax highlighting, markdown, chat panels, and animations, full redraw becomes wasteful.

Dirty regions keep the terminal calm.

struct DirtyRegion {
    x: usize,
    y: usize,
    width: usize,
    height: usize,
}

The engine can merge nearby regions, skip unchanged rows, and write fewer escape sequences. The user sees a smoother UI. The CPU also gets a break.

Text editing needs better data structures

A normal string is not always a good text editor buffer. Insert in the middle, delete ranges, undo, redo, search, and selection all become expensive if the data structure fights you.

This is where ropes are useful. A rope stores text in chunks, so edits in large files do not require copying the whole string every time.

For terminal UI, this matters because text editing is often inside the app itself: prompt boxes, logs, markdown editors, command palettes, and code panes.

Layout is still hard

Even in a terminal, layout is not trivial. You still need flex behavior, grid behavior, min sizes, max sizes, wrapping, overflow, and alignment.

I prefer using a real layout engine instead of inventing a poor version. The hard part is not writing “put this box below that box.” The hard part is making nested layouts behave correctly when the terminal resizes or content changes.

The TypeScript layer should feel simple

A Rust engine is useful only if the developer experience above it is nice.

The TypeScript side should hide the hard parts:

function App() {
  return (
    <column gap={1}>
      <text bold>Build log</text>
      <scrollArea>
        <markdown>{logOutput}</markdown>
      </scrollArea>
      <input placeholder="Ask the agent..." />
    </column>
  );
}

That is the balance I like: Rust inside, TypeScript outside. The engine gets performance and control. The user gets an API that feels familiar.

What I learned

Performance is not only about being fast. It is about doing less work.

In a terminal UI engine, doing less work means:

• Reuse layout state when possible
• Render into a frame, then diff
• Update only dirty cells
• Keep text editing data structures cheap
• Avoid allocation inside hot paths
• Give developers a simple API above the engine

That combination is what makes terminal UI interesting to me. It is systems work, frontend work, and developer tooling all in one place.