Why CLI tools outlive frameworks

Frameworks come and go every few years. Command-line tools built decades ago still run today. That is not luck.

Text in, text out

A CLI's contract is stdin, stdout, and an exit code. That contract composes with anything: a shell script, a cron job, another CLI, a CI pipeline written years later. Nothing about it depends on how the tool is built inside.

A verb, not an app

A framework owns your whole app structure: routing, state, lifecycle, build step. A CLI owns one verb. Owning less means there is less to break when the world around it changes.

Flags are a small surface

Keeping a set of flags backward compatible is far easier than keeping a class hierarchy, a set of lifecycle hooks, and a rendering model compatible. Small surface, fewer ways to force a breaking change.

The shell never gets deprecated

Every other integration layer gets replaced. The shell does not. A tool that speaks shell keeps working long after the framework it was originally paired with is gone.

Replacements keep the flags

When a CLI does die, its replacement almost always keeps the same flags. Users do not relearn -v or --force. The interface outlives the implementation, sometimes more than once.

When a framework is the right call

None of this means frameworks are wrong. Shared UI state, a large team that needs shared conventions, and long-lived interactive apps benefit from a framework's structure. Pick the framework when the problem is coordination, not composition.