Completion Is a Substrate, Not a UI

What the phrase means

Think of a substrate as the soil, not the flowerpot. In biology an enzyme works on a substrate; in hardware transistors sit on a silicon substrate; in platform engineering apps run on compute substrates like Kubernetes. The point is simple: a substrate is primitive, malleable and compositional — raw material you build on. Why does that matter for completion? Because completion can be offered as raw, pluggable parts rather than a finished, prescriptive product.

Emacs: a toolkit, not a toy

Emacs hands you completion as components: matcher, sorter, annotator, action, display. Each piece is a tiny API you can swap, tweak, or replace. Want a different sorting strategy? Swap the sorter. Need custom annotations? Hook in an annotator. It’s not flashy, but it’s powerful. The implicit contrast is completion-as-UI: a polished, vendor-picked experience where every layer is already decided for you. That’s comforting for most people — and maddening for those who like to assemble their own tools.

Why it matters now

This is the old Unix philosophy, reborn for the completion era: do one thing, and let others compose it. There are trade-offs. Substrates demand taste and effort. UIs promise immediacy. But in a world of generative AI, verticalized products, and one-click integrations, the substrate approach preserves agency. It keeps power users tinkering and researchers experimenting. It also keeps ecosystems fertile: plugins, hacks, and happy accidents flourish where layers are exposed.

The narrower, bigger point

So what should we choose? Both have their place. Sometimes you want a polished experience that just works. Other times you want Lego bricks. Emacs’ completion-as-substrate is a reminder: tools that expose primitives age better. They invite creativity instead of closing it down. Isn’t that worth defending in a software landscape that increasingly prefers finished dishes over DIY kitchens?

Sources: chiply.dev, Lobsters