Hacker News Reader

Comment by datadrivenangel | Hacker News Reader

Fighting words!

The author also mentions that JSON is better:

"So if you want to write YAML, you can. But it’ll just take that YAML and turn it into JSON behind the scenes. Then they also have a specific Caddy language. So you can give it the Caddy language and then it turns that into JSON behind the scenes. And you can give it an NGINX config and it’ll turn that into JSON behind the scenes. If you have the cycles and time to spare, that’s probably the best solution for most people…"

View on HN

The fact that JSON doesn't support comments is so annoying, and I always thought that Douglas Crockford's rationale for this basically made no sense ("They can be misused!" - like, so what, nearly anything can be misused. So without support for comments e.g. in package.json files I have to do even worse hacky workaround bullshit like "__some_field_comment": "this is my comment"). There is of course jsonc and JSON5 but the fact that it's not supported everywhere means 10 years later we still can't write comments in package.json (there is https://github.com/npm/npm/issues/4482 and about a million related issues).

At least JSON has a complete and unambiguous specification. If JSON had comments, we wouldn't need YAML 99% of the time.

We actually offer both for configuration files of our software - YAML can be very pleasant to write and read for small datasets or those without much depth, without the overhead of curly brackets and quotation marks on everything. The original problem these formats solve is that people just want a simple nestable key-value structure/format, and both deliver on it - unlike xml. (when do you use an attribute vs a tag and text element?)

> when do you use an attribute vs a tag and text element

When the schema says so — you even get auto-complete for that in any half-decent editor.

I know the history of xml, but just to get back to my original premise: why has a tag (a kind of key in the mind of most readers) multiple "kinds" of values/children in parallel, especially one set that is map-shaped (attributes) while the other is array-shaped (proper children)?

And trailing comments?

Nice to have, but an autoformatter can fix them up if you make a mistake.

Not quite unambiguous! It declares how to parse numbers, but of course the "reference implementation" of JSON (insofar as there is one) is Javascript, in which numbers are floats and hence e.g. are bounded in precision, so the spec actually disagrees with the reference implementation.

I don't think this is true. The original specification (ECMA 404) only covers the formal language, i.e. what are valid documents and not what their memory representation after deserialisation is. A parser that rejects a number because it has too many digits would not be conforming.

rfc8259 is more detailed and it mentions that most parsers will have limited precision and references ieee754 to explain what the expected precision after deserialisation should be for most parsers.

Parsing JSON is a minefield: http://seriot.ch/projects/parsing_json.html

Its spec is not "complete and unambiguous"!

The author is right, both JSON and XML are better for configuration files.

Non ambiguous structure, parsable, nested values, lists, maps, and so on.

If JSON had comments it would be ideal - and for configuration you can support it.

Just check VS Code for what is possible to do directly regarding configuration with JSON, and also to build on top.

YAML is a superset of JSON, so if you prefer JSON, you can - any valid JSON is also valid YAML.

Depending on the yaml parser's quirks.

It is, but then you just use JSON, and can ignore YAMLs design issues and broken design, plus benefit from the mass more readily available and faster parsers!

json5 for complex config files is quite nice.

Reply on news.ycombinator.com