Configuration files are user interfaces

Original Article ↗ Hacker News Discussion ↗

YAML and existing config formats

  • Several comments argue that plain YAML (or familiar formats like INI, TOML, JSON) are “good enough” and that most “YAML hell” is self‑inflicted by misuse (e.g., embedding shell scripts).
  • Others complain that many platforms (Azure Pipelines, GitHub Actions, GitLab CI, Ansible, etc.) effectively force users to write substantial Bash or CLI invocations inside YAML, which makes linting, testing, and reuse hard.
  • Some say this is a platform design problem, not a YAML problem; YAML was meant as data, not as a script host.
  • JSON5, HOCON, KDL, HJSON, protobuf-with-JSON, and gron are mentioned as alternatives that balance human-editability and machine-friendliness.

Are configuration files user interfaces?

  • One side: config files are data; the text editor is the UI. Calling the data itself a “UI” is seen as confused branding.
  • Counterpoint: if writing that data is how a user controls the app, then the file is functionally part of the user interface (even if mediated by an editor).

KSON: interest and criticism

  • Positives:
    • Superset of JSON with YAML-like readability and comments; embeddable blocks for code (SQL, Bash, etc.) with syntax highlighting; automatic formatting and tooling; explicit “end dot” to disambiguate nesting.
    • Aims to be a drop‑in replacement where JSON/YAML act as human-edited interfaces (e.g., Kubernetes manifests, CI configs).
  • Negatives:
    • Syntax perceived by several as ugly or unintuitive; “two thumbs down” reactions.
    • Non–whitespace-sensitive parsing allows “misleading indentation” that can radically change structure from tiny edits; critics argue any config that “needs” a formatter/linter is unsuitable for ad‑hoc editing.
    • Naming rules force quoting some keys (e.g., with Unicode or symbols), seen as a regression from YAML’s “friendly” bare keys.
    • Concern that embed blocks will further normalize mixing real code into configs.
    • Implementation is currently Kotlin-centric; Rust/Python bindings download prebuilt binaries without hash verification and have limited platform coverage, raising supply-chain worries; formal grammar/spec is not yet fully externalized.

Configuration languages vs plain data

  • Some advocate powerful, constrained configuration languages (Cue, Dhall, Starlark, Jsonnet, Pkl, RCL) to support abstraction, validation, and DRY patterns, often generating JSON/YAML as output.
  • Others prefer simple formats (TOML, INI, JSON/JSON5) with strong schemas and tooling, arguing complexity in config usually reflects underlying design problems.
  • Another camp argues “config as code”: using the host language itself (TypeScript, Zig, Python, Lisps, Emacs Lisp, Lua) for configuration, trading off safety and multi-tenant concerns for full expressiveness, types, refactoring, and IDE support.

Broader design and UX observations

  • Distinction is drawn between configuration formats (for humans) and data formats (for machines); trying to make one serve both roles can degrade both.
  • Large, monolithic, highly complex configs are seen as red flags for architecture and UX; some praise systems (e.g., OpenBSD tools, git rebase -i) that design bespoke, readable syntaxes for specific tasks instead of generic object notation.