# Philosophy

> The nine principles every part of Tinka follows, and why each one exists.

Every decision in Tinka traces back to nine principles. They are the reason the framework looks the way it does, and they settle disagreements before they start. When a proposed feature breaks one, the feature changes, not the principle.

## Not a port

Tinka borrows familiar ideas from AdonisJS, Leaf and Laravel, but it does not copy their APIs. A Go framework should feel like Go: explicit, typed and close to the standard library. Some ideas that make sense in TypeScript or PHP have no place here, and some problems get solved in a different way.

## One obvious way

Each task has one obvious way to do it. Flexibility sounds generous, but every option is a decision someone has to make and a variation someone has to read later. Strong conventions let a person review a change quickly and let an agent write it correctly the first time.

## Terse at the call site, explicit in the wiring

Using Tinka takes little code, and every piece of that code is traceable. There is no reflection magic and no hidden global state: you can follow any request or Command from `main()` to the code that handles it. Short code that hides its wiring costs more to debug than it saves to write.

## Standard library first

Tinka types work with `net/http`, `context`, `log/slog` and `errors` instead of replacing them. Your existing Go knowledge applies, and standard library packages, tools and middleware keep working.

## Full-stack, opt-in

Common web needs such as routing, validation, sessions and mail are solved by first-party packages. You import only the ones you use, so an App never carries code or dependencies it does not need.

## One design language

Every package shares the same naming, configuration, errors and testing patterns. Once you have learned one package, the next one reads the same way.

## Docs are product

Nothing ships without its docs page. A feature that is hard to explain is usually hard to use, and writing the docs is how Tinka finds out early.

## Every dependency is a liability

Each dependency is chosen deliberately and the reason is recorded. Dependencies bring updates, security advisories and behavior you do not control, so Tinka prefers a short piece of its own code to a large library it uses a fraction of.

## Zero overhead

Tinka never slows the Go toolchain. No code generation step runs before `go build`, and nothing wraps `go test` or `go run`. Whatever Tinka adds on top is measured before it ships: the Tinka CLI starts in about 14 ms, faster than `go version`. At runtime, an abstraction costs no more than the `net/http` code it replaces.