Library vs Framework: The Real Difference Between tkucli and clap

When comparing tkucli and clap, most differences (syntax, config, features) are surface-level.

The deeper distinction is much simpler:

clap is a library

tkucli is a framework

That single difference changes how you build your entire CLI.

clap: a library

clap is a tool in your toolbox.

It focuses on one responsibility:

• parsing arguments
• validating input
• generating help text

Everything else is up to you.

What that means in practice

• You control how your app is structured
• You decide how commands map to logic
• You handle routing, errors, and flow

#[derive(Parser)]
struct Cli {
    #[command(subcommand)]
    command: Commands,
}

You call clap. It doesn’t call you.

Analogy

clap is like:

a high-end steering wheel and dashboard

It helps you drive—but you still build the entire car.

tkucli: a framework

tkucli is not just a parser—it defines the shape of your application.

You describe your CLI in cli.toml, and the framework:

• generates command structure
• wires routing automatically
• maps arguments into typed handlers
• runs your logic

What that means in practice

• The framework defines the architecture
• You implement handler functions
• Execution flow is managed for you

[[resource]]
name = "users"

[[resource.operation]]
verb = "list"

You don’t call the framework.

The framework calls you.

Analogy

tkucli is like:

a pre-fabricated house

You don’t design every wall—you move in and start using it.

The key concept: Inversion of Control

This is the real dividing line.

clap

• You control everything
• You call into the library

tkucli

• The framework controls the flow
• You plug into predefined extension points

Why this matters

This isn’t just philosophical—it affects how you build.

Choose clap if you want flexibility

• Full control over architecture
• Custom execution models
• Unusual or highly specialized CLI behavior

clap stays out of your way.

Choose tkucli if you want speed and consistency

• Standardized command structure
• Less routing boilerplate
• Built-in CLI + TUI integration
• Strong fit for resource-based tools

Especially useful for:

• CRUD-style tools
• internal platforms
• infrastructure tooling

Trade-offs

Takeaway

The difference isn’t about “which is better”.

It’s about how much control you want over your CLI:

• clap → you design everything
• tkucli → you follow a system and fill in the logic

Both are valid. They just solve different problems.

Project

https://github.com/ggzy12345/tkucli