5 ms·
It makes total sense to omit comments, because JSON is optimized for machine-readability and interoperability (simple spec, simple implementation, no extension
by hp 14y ago
It makes total sense to omit comments, because JSON is optimized for machine-readability and interoperability (simple spec, simple implementation, no extension mechanism, fast to parse). Putting comments in would compromise it for that purpose.
JSON isn't a great config file format, if your config file is meant to be human-edited. But the solution is simple; use a format designed for human editing.
Config files need UI design too.
During Akka and Play 2.0 development, we approached this by starting from the hand-rolled parsers found in Akka 1.2 and Play 1.2 (both had ad-hoc parsers to support a "pretty" config file format). We took the aesthetic preferences of the hand-rolled parsers seriously, and came up with HOCON: https://github.com/typesafehub/config https://github.com/typesafehub/config (scroll down to "JSON Superset"), https://github.com/typesafehub/config/blob/master/HOCON.md https://github.com/typesafehub/config/blob/master/HOCON.md
The HOCON format is a superset of JSON and also happens to be mostly compatible with the Play and Akka 1.2 ad hoc parsers (which were independently developed, so two data points on what people wanted).
HOCON is roughly similar to YAML in complexity. Like YAML the spec is pretty long ( http://www.yaml.org/spec/1.2/spec.html http://www.yaml.org/spec/1.2/spec.html ). And the Typesafe Config and SnakeYAML jars have pretty comparable amounts of bytecode in them.
HOCON or YAML would be terrible formats for an API or something like that, and they're painful to implement, but I strongly prefer them to JSON for human-maintained configuration.
Anyway, I think the genius of JSON was its focus on machine interoperability rather than trying to do everything, that's why it works so well for machine interoperability.
But it doesn't mean you have to use it for everything.
- gnuvince 14y agoFrom json.org: "JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate." Humans are mentioned before machines. Comments improve human readability. Furthermore, comments are very simple to implement, and don't lower the ease of parsing.
- philjohn 14y agoAnd as Crockford said, if you want comments in your JSON, knock yourself out - just strip them out before handing it over to your parser.
- TazeTSchnitzel 14y agoYeah, but JSON is a data interchange format. It's like adding the ability to add comments to arbitrary binary data, it's rather pointless. It's supposed to be human readable, but ultimately it's for machines. It's just easier to debug.
- cube13 14y agoThere are 3 mutually conflicting goals of JSON: 1. Machine parsing/generation 2. Human parsing/generation 3. Ability to transmit it in a parsable format through HTTP #1 conflicts with both #2 and #3. It conflicts with #1 because binary data formats are much easier to parse, and are generally smaller on the wire than plain text formats. Also, it conflicts with #3 for the same reason, since HTTP is a plain text format, and JavaScript generally deals with plain text better than binary data. #2 conflicts with #3, because comments are nice for human readability, but should never be sent on the wire, because they are not necessary to parse the sent data. If your comment is important, it should be a data element that's sent on the wire. The end result is a compromise. Since two of the concerns effectively make comments useless, the compromise should be towards those two. In addition, the reason given by Crockford makes quite a bit of sense. JSON, much like XML, is a format for the transmission of data. Everything in a given JSON object should be important. It's not a programming language, which means that control directives are unnecessary.