CLIs Are Making A Comeback

Command-line interfaces are back in fashion—not because old Unix tools stopped working, but because modern terminals and developer workflows made CLI software feel faster, richer, and easier to build on. The shift shows up in rising activity around new CI-adjacent utilities and in a wave of “rethink and reinvent” projects that refine classic Unix problems instead of merely cloning them.

The discussion traces CLI’s lineage to early interactive computing: Unix’s first version in 1971, followed by a long run of terminal-first tools that shaped everyday workflows. Between roughly 1995 and 2015, momentum slowed as graphical interfaces and integrated development environments absorbed more users. The argument isn’t that CLIs became obsolete; it’s that fewer people needed to learn them when editors and GUIs handled more tasks behind the scenes.

In recent years, terminals have changed dramatically. They can render more color, Unicode symbols, and even inline images, while terminal apps now coexist with graphical user interfaces. That expanded capability, combined with modern editor integrations, has made CLI tools feel less like barebones text and more like interactive workspaces. As a result, developers increasingly build new command-line utilities—or redesign existing ones—to match current expectations for speed, usability, and ergonomics.

A key theme is that many “new” tools aren’t replacements so much as different experiences. Ripgrep (rg) is treated as a case study: it’s not meant to be a drop-in for grep, and it can behave differently in performance and resource usage. The broader point is that tools evolve by exploring the solution space—choosing different tradeoffs for common tasks—rather than chasing novelty for its own sake.

The conversation also frames CLI resurgence as a learning loop from decades of sharp edges. Over time, users and maintainers have absorbed lessons about configuration burden, confusing defaults, and brittle error messages. Good defaults matter because they prevent catastrophic outcomes and reduce setup time; the discussion cites a real-world cloud incident where a bad default led to accidental deletion, underscoring how dangerous “test-like” defaults can be.

Editor and shell ecosystems become another battleground for these principles. Fish is praised for sensible defaults and a prompt/autocomplete experience that works immediately, while critics object to its distinct configuration syntax. Neovim is positioned as the community’s Vim-compatible path forward—improving capabilities like syntax parsing and LSP integration—yet the tradeoff is that much functionality is hidden behind plugins and configuration layers.

Finally, the talk connects tool design to human factors: error messages should point users to what went wrong and how to fix it; documentation should be discoverable without constant manual lookups; and common workflows should be streamlined so users don’t need to memorize arcane flags. Even build tooling is discussed through this lens—make remains popular partly because it’s ubiquitous, while newer systems compete on ergonomics and task-runner friendliness.

Overall, the comeback isn’t just about new software. It’s about applying accumulated UX lessons to terminal-first tools—so CLIs stay powerful while becoming more approachable, more reliable, and more aligned with how developers actually work today.