The Path Dependence of YAML Templates

Why did YAML templates come to dominate configuration? YAML was initially released a month after JSON (2001).

A hypothesis is that YAML is not only popular because it is more human-readable/writable than JSON but also because it is significantly more machine writable as a raw string.

• No trailing commas. Adding or removing elements of an array in YAML can be done without knowing the length of the list. (2) Curly brackets are slightly more complicated than indentation — brackets require state tracked in a stack, and indentation can simply be a counter (no need to close array brackets or object brackets)

• Quoted strings are not always necessary. For configuration that often already has special character constraints, it’s easier to print the string rather than worry about quoting.

• YAML is a subset of JSON — You’ve always been able to create a Kubernetes object with a JSON configuration, but adding support for YAML was trivial — the YAML parser in Go just converted it to JSON and then used the standard library’s JSON parser. So you could do both with minimal dependencies. (This started with YAML v1.2)

• Multiple documents in a single file — If you are templating YAML, you might not know how many documents you will output. It’s sometimes easier for systems to delimit documents with the YAML `---` than write to multiple files. JSON does not have this capability.

• Subsets of YAML documents are often valid YAML themselves. This lets you separate out the templating logic and build a document in a single pass.