The Modern CLI Renaissance
A perceived “renaissance” in command-line and terminal user interfaces is prompting debate over how far new tools should diverge from classic Unix utilities. Commenters weigh the benefits of opinionated defaults, richer TUIs, and modern terminal protocols against concerns about surprise behavior, performance over slow links, backward compatibility, and excluding users on modest hardware. Broader questions emerge about whether developers are over-optimizing for their own workflows, whether CLIs are displacing or complementing GUIs, and how much innovation is worth sacrificing the simplicity and predictability that made the shell so durable.
Defaults and .gitignore Behavior (ripgrep/fd debate)
- Large subthread on whether modern tools like ripgrep and fd should respect
.gitignoreby default. - One side: defaults should mirror classic tools (grep/find) and be unfiltered; hidden filtering creates “missing results” failures that are harder to detect than “too many results.”
- Other side (including the ripgrep maintainer): respecting ignore files is the central UX innovation; most code searches don’t want
node_modules, build artifacts, or VCS junk. Changing now would be a massive breaking change. - Docs for ripgrep prominently state this default; critics respond that many users install via package managers and never see them.
- Suggested compromises (warnings to stderr, flags to specify ignore files) are mostly rejected as noisy or cumbersome; recommended workaround is aliases (
rg -uuu, etc.).
Design Principles and Failure Modes
- Long meta-discussion about “Principle of Least Surprise,” “Norman doors,” and failure analysis.
- One camp argues: better to err on over-disclosure (too much output) because it naturally signals the need to filter, whereas silent omissions can be catastrophic and invisible.
- Others counter that “least surprise” is subjective; false positives can be just as harmful in information retrieval, and good defaults plus clear docs are more important than strict conservatism.
- Strong disagreement on whether these are objective engineering tradeoffs or subjective aesthetic preferences.
TUI and Terminal Renaissance
- Many celebrate modern TUI frameworks (Ratatui, Bubble Tea, Textual) and curated lists of new tools (e.g., gdu, lazygit, ripgrep-all).
- Some lament abandoning terminfo and hard-coding escape sequences; others argue the de facto xterm standard is sufficient.
- Kitty’s keyboard and image protocols are praised as “21st‑century” terminal features, though its security model and lead developer’s reputation are contentious.
- Example given of a statically linked X11 paint app as counterpoint to “TUI is the only way” for static, mouse-driven apps.
Shells, Portability, and New Abstractions
- Desire for a “new default shell” not bound to 1970s terminal assumptions, but strong inertia: scripts must run everywhere, so POSIX sh/Bash remains baseline.
- New shells (fish, Nushell, Oil, Ion, eshell) and PowerShell are discussed as more modern, typed, or object-based, but non-portability and long transition timelines are major barriers.
- Some argue shells should make it easier to use “foreign” languages (Python, Lua, TS) as scripts; others note this was tried historically and built-in shell languages won out.
CLI vs GUI and Web
- One faction sees a “new dark age”: web and Markdown culture have pulled developers toward text, stunting GUI innovation and user productivity.
- Others strongly defend text/CLI: composability, automation, scripting, accessibility, and universality across wildly different hardware and networks.
- Concerns raised that “modernizing” terminals (heavy TUIs, image protocols, chatty networked features) can recreate web-style bloat and ignore slow links and small devices.