tui-fundamentals

TUI Fundamentals, Architecture, and Framework Selection

Use this skill when the task is about the shape of the terminal product: what kind of TUI to build, which abstraction to use, how to organize state, or whether a full-screen terminal UI is the right answer.

First decision: is a TUI appropriate?

Prefer a rich TUI when users need continuous visual feedback, multi-step navigation, keyboard-driven exploration, selection among many items, or a dashboard-like control surface. Prefer a line-oriented CLI, prompts, or plain output when the flow is short, scriptable, primarily automation-focused, or likely to be used by screen readers and CI systems.

A production terminal product often ships both:

• A scriptable CLI surface for automation, accessibility, logs, and non-TTY use.
• An optional TUI for exploration, monitoring, bulk selection, or guided workflows.

Architecture rules

1. Separate model, update, and view. Business state should not print directly to the terminal. Rendering consumes state; input produces events; update logic transforms state.
2. Treat terminal size as input. Layout must be recomputed from width and height on every resize. Never bake in one terminal size.
3. Own terminal lifecycle in one place. Raw mode, alternate screen, mouse, focus, keyboard protocols, and cleanup should be centralized.
4. Make every action keyboard-operable. Mouse support is an enhancement, not the primary navigation model.
5. Design for degradation. TERM=dumb, non-TTY output, missing color, Windows console differences, tmux/screen, SSH, and CI should have clear behavior.
6. Avoid hidden global terminal writes. Logs, progress, and background task output must not corrupt the screen.

Framework selection quick matrix

Need	Strong default
Rust full-screen app with precise rendering	Ratatui + Crossterm
Python product-grade app with widgets, CSS, async workers	Textual
Python rich output, progress, tables, markdown, logs	Rich
Python REPL, shell, completions, complex prompt input	prompt_toolkit
Classic dependency-light Unix TUI	curses/ncurses
Go Elm-style app with composable commands	Bubble Tea + Bubbles + Lip Gloss
Go batteries-included forms/tables/tree views	tview over tcell
Go portable low-level cell engine	tcell
React-style terminal components in Node	Ink
Node DOM-like full-screen widgets	Blessed
.NET full-screen views	Terminal.Gui
.NET rich CLI output and prompts	Spectre.Console

Read references/framework-selection.md before committing to a framework in a new project.

Product design checklist

• Define the primary user journey in one sentence.
• Decide whether the app is full-screen, inline, prompt-based, or hybrid.
• List required environments: Windows Terminal, classic conhost, macOS Terminal, iTerm2, GNOME Terminal, Alacritty, SSH, tmux/screen, CI, and logs.
• Define minimum terminal dimensions and the small-screen fallback.
• Define exit keys, destructive confirmation rules, and recovery instructions.
• Define non-interactive equivalents for every essential action.
• Decide how help is exposed: footer hints, ?, command palette, --help, docs.

Failure modes

• Building a full-screen UI for a workflow that should be scriptable.
• Choosing a low-level escape-sequence approach when a framework already solves layout, input, cleanup, and testing.
• Mixing business logic with terminal writes, making tests brittle and rendering inconsistent.
• Ignoring screen-reader users, CI, pipes, and TERM=dumb until late.
• Assuming color, Unicode icons, Nerd Fonts, or mouse support are always available.

Reference files

• references/framework-selection.md - Detailed ecosystem comparison and decision tree.
• references/tui-architecture.md - State, event, lifecycle, logging, and distribution patterns.