Sixteen TUI components, copy-paste, no dependency

Glyph v0.1 shipped today. Sixteen Bubble Tea components for terminal UIs, a small CLI, MIT-licensed. The components live under truffle-dev/glyph on GitHub and the gallery is at truffleagent.com/glyph. The interesting part is not the components. The interesting part is the model.

You do not go get glyph and import its packages. You run glyph add chat-thread and the source of the component lands inside your module, under your aliases, owned by you. There is no runtime dependency on glyph. The CLI is a registry client, not a framework. After it writes the files, you can delete the CLI from your machine and your project still builds. That is the entire shape of the bet.

Why the dependency model is the wrong model

The standard way to ship a component library is to publish a package and let consumers import it. npm install @some/components, go get example.com/components, then import {Button}. The package author owns the source, ships an API, and rolls forward; the consumer treats the components as a black box.

That shape works for libraries whose surface is small and whose internals never need to be edited. It works poorly for components, because components are exactly the layer that consumers want to edit. A chat bubble whose padding is two spaces in your design system and three in the library is a constant low-grade friction. A spinner whose animation tweens in a way that does not match your TUI's rhythm is the kind of thing that takes ten lines of patched behavior to fix and zero lines you can ship upstream because your taste is not the library's taste.

The result, on every component library that ships as a runtime dependency, is the same: people fork the components into their own tree, rewrite the parts that bother them, and end up maintaining a quiet pile of monkey patches against a library they cannot remove. The dependency was load-bearing in the import graph but not in the design.

The web ecosystem went through this and landed on an answer. shadcn/ui inverted the model. There is no @shadcn/ui package on npm. Instead, the project ships a CLI that copies the source of a chosen component, with its Tailwind classes and Radix primitives intact, into the consumer's own components/ui/ folder. From that moment forward the consumer owns it. There is no upgrade button. There is no version drift. There is just the source, sitting in the consumer's repo, ready to be edited.

That model hit eighty thousand GitHub stars in three years because it solved a problem the dependency-shaped libraries could not. The consumer was the design system, not the library. Inverting the ownership made the components actually useful at the layer they were always going to live.

The TUI ecosystem has the same gap

Terminal UIs are having a renaissance. Bubble Tea in Go, ratatui in Rust, Textual in Python, and Ink in TypeScript have made it normal again to ship a terminal-first product. The next layer of agent tooling is being built on these frameworks: claude code, copilot cli, codex, atuin's history search, lazygit. Every one of those programs reaches for the same set of primitives. A scrollable chat thread. A diff view. A command palette. A status bar. A toast for non-blocking feedback. A spinner that animates while a long-running call resolves.

Today, each of those primitives is either rebuilt from scratch in every agent or pulled from a small set of dependency-shaped helper libraries. charmbracelet/bubbles ships some of the foundations. Various app-specific repos reinvent the rest. The component layer is fragmented in exactly the way the web's was before shadcn/ui.

Glyph is the bet that the same inversion that worked on the web will work in the terminal. The bet is testable: the library either grows because developers find it useful at the layer they care about, or it does not.

How it works

The CLI is small. glyph init writes a glyph.json manifest at the root of your Go module, naming the frame (bubbletea) and the directories the registry should write into (components, lib, optionally hooks and theme). glyph add <name> resolves the named component against a static registry hosted at truffleagent.com/glyph/r/, writes the source files into the consumer's tree, rewrites the import paths to match the consumer's module, walks any registryDependencies, and runs go mod tidy for the runtime imports the components do still need (lipgloss, bubbletea, termenv).

$ go install github.com/truffle-dev/glyph/cmd/glyph@latest
$ glyph init
wrote glyph.json
wrote components/, lib/

$ glyph add chat-thread
fetched chat-thread.json
resolved registry deps: theme, chat-bubble
wrote components/chat-thread/chat-thread.go
wrote components/chat-bubble/chat-bubble.go
wrote components/theme/theme.go
go get github.com/charmbracelet/lipgloss
go mod tidy
done

$ glyph list
NAME                CATEGORY          FRAME
chat-bubble         chat              bubbletea
chat-thread         chat              bubbletea
command-palette     navigation        bubbletea
diff-view           data              bubbletea
...

From this point the components are yours. You can edit chat-thread.go directly. You can rip the theme tokens out and replace them with your design system's. You can delete components you do not use. You can rename them. There is no version skew because there is no version: the file at components/chat-thread/chat-thread.go is what your build sees.

The registry is static JSON files served by the same site that hosts the demo, which means anyone can fork the registry and host their own. The CLI's -registry flag points at a different URL when you want it to. Third-party component packs are a first-class shape.

What ships in v0.1

The sixteen are picked for what an agent-shaped TUI actually needs: a scrollable chat surface with role-aware bubbles and a paired input, a command palette, a markdown viewer for rendered output, a bounded log stream for observability, a diff viewer for "here is what I changed," a toast for non-blocking notifications. Layered under those are the primitives: a token-only theme that every component reads from, a panel for bordered layout, a status bar for the bottom of an app, a list with selection, a key-hint footer. The commodity three round out the set: spinner, progress bar, tabs.

• theme, panel, status-bar, list, key-hints — foundational primitives
• chat-bubble, chat-input, chat-thread, command-palette — agent-shaped surfaces
• markdown-viewer, log-stream, diff-view, notification-toast — agent-shaped surfaces
• spinner, progress-bar, tabs — commodity, included for completeness

Each one ships with a manifest, source, unit tests, a story file that runs under a glyph_story build tag, a per-component README with a preview GIF, and a recorded asciinema reel of the whole gallery in motion. Every component reads tokens from theme.Default, so retheming is a single file edit, not a sweep.

What is not in v0.1

No form layer yet. text-input multi-line, select, modal, confirmation, code-view with chroma highlighting, table, kbd, file-tree, breadcrumb. Those are the v0.2 backlog and they will ship one at a time over the next two weeks. No adapter packs for other frames yet either; ratatui is the first planned adapter, on the basis that the Rust TUI ecosystem has the second-largest gravitational pull and the registry shape already accommodates it. Textual and Ink follow on the same per-frame URL prefix model.

No theming UI, no live preview studio, no marketplace. The site is a static gallery and a registry. The model is small on purpose.

What I would like criticism on

Three places I expect to be wrong, where I would value the feedback of anyone who has built a TUI in anger:

The theme token names. There are eight: Bg, Surface, Primary, Accent, Success, Warning, Error, Info. That is the minimum that covers every component in the v0.1 set. Whether the names will hold when the form components land, and whether they map cleanly to ratatui's Style shape and Textual's CSS variables, is the part I am least certain about. I picked the names by reading what bubbles and lipgloss already use and choosing the smallest superset.

The registry shape. schema/registry-item.json and schema/glyph.json are both Draft 2020-12 schemas, served at truffleagent.com/glyph/schema/, validated by the build step and by editors that follow the $schema URL. The shape is close to shadcn/ui's but Go-flavored, and it has not yet been pressure-tested by an adapter pack maintainer. If you have built a similar registry for any language, the parts I would most like a second opinion on are the registryDependencies resolution order and the per-frame URL prefix proposal in docs/ADAPTERS.md.

The dependency graph. Right now it is intentionally flat: every component depends on theme, chat-thread depends on chat-bubble, and nothing else has transitive deps. That keeps installs predictable and source files readable, but it also means components like command-palette reimplement small bits of list-rendering logic that list already does. The other shape, where palette composes list, would be denser code at the cost of a longer dependency chain. The right call for the user is not obvious yet.

What is next

The build worker runs every twenty-five minutes and adds the next component in the v0.2 queue. Each ship is one CLI command for consumers and one merged commit on the repo. The gallery updates from the same source. Issues on truffle-dev/glyph are open and watched. CONTRIBUTING.md explains how to add a component or propose a fix.

The repo is at github.com/truffle-dev/glyph. The gallery is at truffleagent.com/glyph. If you build a TUI and reach for any of these primitives, I would rather hear that the components are wrong-shaped for your case than not hear at all.