3 ms·

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 behi

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…"

dharmab 3y ago
At least JSON has a complete and unambiguous specification. If JSON had comments, we wouldn't need YAML 99% of the time.
- rf15 3y ago
  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?)
  - kaba0 3y ago
    > 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.
    - rf15 3y ago
      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)?
- shaftway 3y ago
  And trailing comments?
  - dharmab 3y ago
    Nice to have, but an autoformatter can fix them up if you make a mistake.
- Smaug123 3y ago
  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.
  - stkdump 3y ago
    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.
- jiggawatts 3y ago
  Parsing JSON is a minefield: http://seriot.ch/projects/parsing_json.html http://seriot.ch/projects/parsing_json.html Its spec is not "complete and unambiguous"!
coldtea 3y ago
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.
- enoch_r 3y ago
  YAML is a superset of JSON, so if you prefer JSON, you can - any valid JSON is also valid YAML.
  - politelemon 3y ago
    Depending on the yaml parser's quirks.
  - coldtea 3y ago
    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!
- makapuf 3y ago
  json5 for complex config files is quite nice.
hn_throwaway_99 3y ago
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 https://github.com/npm/npm/issues/4482 and about a million related issues).

dharmab 3y ago

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

rf15 3y ago
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?)
- kaba0 3y ago
  > 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.
  - rf15 3y ago
    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)?
shaftway 3y ago
And trailing comments?
- dharmab 3y ago
  Nice to have, but an autoformatter can fix them up if you make a mistake.
Smaug123 3y ago
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.
- stkdump 3y ago
  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.
jiggawatts 3y ago
Parsing JSON is a minefield: http://seriot.ch/projects/parsing_json.html http://seriot.ch/projects/parsing_json.html Its spec is not "complete and unambiguous"!

coldtea 3y ago

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.

enoch_r 3y ago
YAML is a superset of JSON, so if you prefer JSON, you can - any valid JSON is also valid YAML.
- politelemon 3y ago
  Depending on the yaml parser's quirks.
- coldtea 3y ago
  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!
makapuf 3y ago
json5 for complex config files is quite nice.

hn_throwaway_99 3y ago

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 https://github.com/npm/npm/issues/4482 and about a million related issues).