Go for Terminal UIs

Why Go fits the terminal

The hard part of any interactive TUI is concurrency. The keyboard, a ticking clock, a network request, a file watcher, and a resize event all fire asynchronously, and every one must funnel into a single render without corrupting shared state. In most languages that means callback soup, an async runtime, or a hand-rolled select loop.

In Go this is the language's home turf. A goroutine does the blocking work; it sends a value on a channel; a single select loop receives it and updates state. That is the event loop — Bubble Tea's runtime is literally a goroutine reading messages off a channel and calling your Update. You get the hard part for free, and you get it with the race detector (go test -race) to prove you got it right.

One static binary, trivial cross-compile

go build produces a single statically-linked executable — no runtime, no interpreter, no shared-lib hunt. Cross-compiling is one env var:

GOOS=linux   GOARCH=amd64 go build -o mytool
GOOS=darwin  GOARCH=arm64 go build -o mytool   # Apple Silicon
GOOS=windows GOARCH=amd64 go build -o mytool.exe

For a CLI tool you want people to install, this is what matters. curl the binary, drop it in $PATH, done — no pip, no node_modules, no glibc version mismatch. It is why most modern "download and run" terminal tools are a Go (or Rust) binary.

Fast compile = tight UI iteration

A TUI is a visual artifact: you tweak a border, a color, a layout constant, and you want to see it now. Go's sub-second incremental compiles make the terminal your live canvas. Pair with vhs to record the result as a GIF for a README without a screen recorder.

The stack

The center of gravity is Charm (charmbracelet). In Feb 2026 they shipped v2 of the three flagship libs — Bubble Tea, Lip Gloss, Bubbles — the first breaking changes in the project's six-year history, with a new ncurses-derived "Cursed" renderer and terminal synchronized-output mode 2026 to kill flicker and tearing.

The retained-mode alternative: tcell + tview

Bubble Tea is immediate-mode — you re-describe the whole screen every frame. For widget- and form-heavy retained UIs (a settings panel with focus traversal, dozens of stateful boxes) the older tcell + tview stack is often a better fit.

The core pattern: MVU

The model is MVU (Model-View-Update), borrowed from Elm. Three methods on your state struct:

type Model struct { /* your app state */ }

func (m Model) Init() tea.Cmd                            // kick off initial async work
func (m Model) Update(msg tea.Msg) (tea.Model, tea.Cmd)  // handle one event, return new state
func (m Model) View() tea.View                           // pure render of current state

• Init returns a tea.Cmd — the first async job (or nil).
• Update receives one message (keypress, tick, custom struct), returns the next model plus optionally another command. This is the single choke point where all state changes happen — no shared-state races by construction.
• View is a pure function of state. In v2 it returns a tea.View struct: declarative, you set fields, the runtime handles cursor and mode.

tea.Cmd is how async meets the loop

A Cmd is just func() tea.Msg — it runs in its own goroutine, does the blocking thing (HTTP, disk, sleep), and returns a message the runtime feeds back into Update. That is the whole async story:

func fetchUser(id int) tea.Cmd {
    return func() tea.Msg {
        u, err := api.Get(id)          // blocks — fine, it's a goroutine
        if err != nil {
            return errMsg{err}
        }
        return userMsg{u}              // becomes the next Update's msg
    }
}
// in Update: case userMsg: m.user = msg.u

No callbacks, no promises. Goroutine in, message out, single-threaded state. This is the pattern the whole ecosystem is built on.

Composing sub-models

A big TUI is a tree of small MVU models. The parent embeds children, forwards messages down, and collects commands up with tea.Batch — which fans multiple commands out to goroutines concurrently while the loop stays single-threaded:

func (m App) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    var cmds []tea.Cmd
    switch msg := msg.(type) {
    case tea.KeyMsg:
        if msg.String() == "tab" { m.active = m.active.next() }
    }
    var cmd tea.Cmd
    m.list, cmd  = m.list.Update(msg);  cmds = append(cmds, cmd)
    m.input, cmd = m.input.Update(msg); cmds = append(cmds, cmd)
    return m, tea.Batch(cmds...)
}

Where it wins — proof in the wild

Star counts and last-push dates pulled live from the GitHub REST API, 2026-07-04.

The one honest boundary

Graphical / GPU-accelerated UI is not the terminal's job, and therefore not Go's job here. A cell grid of styled text can't be a pixel canvas: no real image compositing (sixel/kitty-graphics are hacks, not a UI model), no GPU shaders, no sub-cell layout, no rich typography. If the product needs those, you've left the terminal — a different toolchain conversation entirely. See the golang hub #ui section for where Go's desktop/GPU GUI story has real gaps. Inside the terminal, though, Go isn't a compromise — it and Rust are the two stacks people reach for first.