They were chucked out because, according to the guy who defined it, people started using them for parsing directives, which hurt interoperability because now you needed to be sure that the parser would both read the comments and interpret them correctly. Suddenly, those comments might make otherwise identical files parse differently. If the whole point is that it’s reliable and machine-readable, keeping it to the minimal set of features and not extending it any way whatsoever is a good way to ensure compatibility.
What you can do is define some property for comments. It’s not standardised, but you could do stuff like
{"//":"This is a common marker for comments","#":"I've never seen that as a property name, so it might be safe?","_comment":"Property names with underscore for technical fields seem common enough as well, and it's semantically explicit about its purpose"}
And also, JSON was intended as a data serialisation format, and it’s not like computers actually get value from the comments, they’re just wasted space.
People went on to use JSON for human readable configuration files, and instantly wanted to add comments, rather than reconsider their choice because the truth is that JSON isn’t a good configuration format.
People went on to use JSON for human readable configuration files
Speaking from my own experience, “I could also use this for…” seems to be a ubiquitous programmer affliction. Single-purpose tools that are great at their thing tend to be short-lived unicorns until someone starts sticking other parts onto them for additional functionalities, taking off the horn because it’s in the way for some thing or other, and somehow we end up with yet another multi-function-tool that does a lot of things poorly.
They were chucked out because, according to the guy who defined it, people started using them for parsing directives, which hurt interoperability because now you needed to be sure that the parser would both read the comments and interpret them correctly. Suddenly, those comments might make otherwise identical files parse differently. If the whole point is that it’s reliable and machine-readable, keeping it to the minimal set of features and not extending it any way whatsoever is a good way to ensure compatibility.
What you can do is define some property for comments. It’s not standardised, but you could do stuff like
{ "//": "This is a common marker for comments", "#": "I've never seen that as a property name, so it might be safe?", "_comment": "Property names with underscore for technical fields seem common enough as well, and it's semantically explicit about its purpose" }And also, JSON was intended as a data serialisation format, and it’s not like computers actually get value from the comments, they’re just wasted space.
People went on to use JSON for human readable configuration files, and instantly wanted to add comments, rather than reconsider their choice because the truth is that JSON isn’t a good configuration format.
Speaking from my own experience, “I could also use this for…” seems to be a ubiquitous programmer affliction. Single-purpose tools that are great at their thing tend to be short-lived unicorns until someone starts sticking other parts onto them for additional functionalities, taking off the horn because it’s in the way for some thing or other, and somehow we end up with yet another multi-function-tool that does a lot of things poorly.