Why the Build Tool Is a TUI

A terminal UI looks primitive next to a web app or a native desktop app, and those alternatives are genuinely more capable. So why does [yoe] use a TUI? The latest video walks through the reasoning, and it comes down to one thing: most of the work already happens in the terminal, and a TUI build tool sits right next to it.

We already live here

Open a developer’s terminal and look at what’s running. An editor — Helix or Vim — for finding files and making changes. A file manager like Yazi for moving through build directories. lazygit for the day-to-day git work. Zellij as a multiplexer, holding saved sessions that you can reattach from another machine — the demo is recorded from a laptop attached to a workstation session — split into named tabs and panes. ripgrep for searching the tree.

These tools are fast, keyboard-driven, and composable. They are where the work happens. A build tool that opens a separate window asks you to leave that environment every time you switch between building the system and changing the code.

Proximity is the feature

Because [yoe] is a TUI, it starts up inside that same environment. Highlight a unit and press e, and you land in the same editor you use for everything else — not a built-in editor that almost works, but your editor. Press $ and you drop into a shell in that unit’s build directory, where yazi, rg, and the rest of your toolkit are already waiting.

A TUI is not the most powerful interface for any single one of these jobs. A native app could draw a richer view of any one of them. But the TUI inherits an effectively unbounded set of powerful, programmer-focused tools for free, and the toolkit [yoe] is built on makes wiring up to them straightforward. The build tool stops being a destination you visit and becomes one more pane in the environment you never left.

Speed, and hands on the keyboard

The terminal tools share another trait: you drive them from the keyboard. Switching units, opening an editor, shelling in, searching — each is a keystroke, not a trip to the mouse to hunt for the right window. Hands stay on the keyboard, and the loop between I want to change this and the change is made stays short.

That is the whole argument. A TUI is a constrained surface — characters on a screen, no pixels to spare on chrome. The constraint buys speed, keyboard control, and a clean seam between the build tool and every other tool a developer already trusts.

Why this matters

The first goal in What a Modern Embedded Linux Build System Could Look Like was to shrink the loop between an idea and a running image. A lot of that loop is the friction of moving between tools. Choosing a TUI removes a category of that friction by refusing to pull you out of the environment where the rest of the work already lives.

The full set of walkthroughs is on the Videos page. What part of the workflow would you like to see next? Open a discussion or send a note.