The killer feature for me over JSON is comment support, it's definitely useful to add todo comments etc.

Yep, so true. Any decent config file that will be seen/edited by a human needs comment support. And any file that will not be seen by a human could be json (or whatever).

Yeah this is a huge selling point of YAML. JSON should have comments added to the spec. The other benefit to YAML is human readability, which is usually better in YAML compared to JSON. A specific glaring example of this is when there are long string-literal snippets inside the document, in YAML this is massively more readable than in JSON.

JSON shouldn't have comments added to the spec, because people shouldn't be trying to read or write JSON. It's an application interchange language, meant to be written and read by machines. YAML is a markup language, meant to be written and read by people. Ever notice how most YAML libraries don't even have a "dump" function?

>It's an application interchange language, meant to be written and read by machines.

Not entirely true, JSON is based on Javascript objects, it was meant to be written and read by humans just like Javascript, INI or any other basic serialized data format, or text-based programming language. If JSON were truly never meant to never be viewed or edited by human beings, it would have been published as bytecode.

>> Ever notice how most YAML libraries don't even have a "dump" function?

No. I guess unless you’re using something half-baked, I suppose. Machines need to be able to edit configs either way.

Hum... We have a bad historic of success in deciding that this or that stuff is for machine consumption only.

> JSON should have comments added to the spec.

See also ~5 years ago: https://news.ycombinator.com/item?id=7325735

You can just use JSON with comments though. If you have sufficient control over the technology in question to be able to completely change it to a YAML parser, surely you can change it to be a JSON+Comment parser too. See: VS Code's config files.

But you can restrict yourself to JSON+Comments and call it YAML; it isn't idiomatic YAML, but it's still valid YAML.

> You can just use JSON with comments though.

Then it's not valid JSON, and if you try to treat it as such bad things will happen.

My point is that if you're in sufficient control of the stack to be able to convert the whole thing over to YAML, you could just as easily convert the whole thing over to JSON+Comments. And of course bad things would happen if you treat JSON+Comments as JSON, but similar bad things would happen if you treat YAML as JSON, so I don't see your point. It's not like people are trying to send their tsconfig's on the wire as "application/json" and expecting arbitrary parsers to support it.

When you think about it, JSON lacks so much (check JSON5 for what it's lacking), it's hard to believe even a comment is not allowed when pretty much anything else allows, which is a showstopper by itself.

> YAML is way more easily human readable than JSON, so I started to appreciate it for readability purposes.

> I guess YMMV, but after you've used both YAML and JSON for a while, you might appreciate YAML a little bit more.

I've used JSON a lot, and XML and s-expressions and MessagePack and ini and YAML and a whole bunch of other formats.

I usually have to fire up Google to read YAML. YAML is the only one where I routinely have to Google for a syntax cheatsheet and wade through tables of redundancy and edge-cases.

YAML made sense before JSON became a thing. Why people persist with it in new projects is baffling to me.

a raw YAML file is readable with your eyes. A Json file needs to be prettified before you go thru it. Json is good for APIs but is not made for readibility.

We must disagree with what "readable" means then. I find JSON readable (as long as it's nicely layed out, e.g. by piping through 'jq "."'), in the sense that I can skim over the structure looking for [/]/{/}/". If I want to read some of the content, like a string, I just need to read '\"' as '"' and '\\' as '\', which is a small constant cost per (usually rare) occurrence.

With YAML it's difficult to even know the structure of what I'm looking at, due to anchors and extensions. It's also hard to discern structure from skimming, since strings can appear unquoted, and may contain unescaped lexical tokens (depending on which particular symbols it started with); hence we must carefully consider each and every character, rather than just skimming for the next token.

If I know I'm looking at a perfect YAML file, than I should be able to guess the gist of what it says, since I can make assumptions about what the syntax means. If I want to be sure, I'd be Googling for cheatsheets. Yet as a programmer, I mostly look at files when they're buggy, meaning I can't just assume that, say, an unescaped quotation mark won't terminate the string; or that a certain piece of text is allowed to run across multiple lines; or that the indentation corresponds to the nesting; etc.

That's what syntax highlighting is for.

I use notepad++ for YAML. Besides coloring what it thinks I'm thinking, it displays vertical lines corresponding to the indentation levels.

(I prefer INI/TOML whenever I can help it; hierarchies in TOML are so counterintuitive that it incentivizes a simple flat structure. But then, some things are irremediably hierarchical)

Is it really though? The implicit typecasting gives rise to very unexpected results, that you'd never get with JSON. See: https://hitchdev.com/strictyaml/why/implicit-typing-removed/

Have you considered alternatives like TOML or JSON5?