Yeah, and if people would solely use them as comments for humans to read... I'm with you.
But they won't. A big part of the reason comments weren't included in JSON is that people tried to get clever with them.
Directly quoting Crockford:
> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability.
And while I'd also love to occasionally throw a comment in a json file, I don't want to have to deal with any of the headaches they would have created in the ecosystem.
And to be fair to Crockford here - it's not like he wasn't aware this was a downside. He even released a tool as a preprocessor for JSON if you wanted to put comments in: https://www.crockford.com/jsmin.html
JSON intentionally chose to stay as simple and compatible as possible, and personally - I think that constraint was the right call.
If I'm writing files I want to throw a lot of comments in... It usually means I should move to something like YAML instead.
Again - JSON is terrible at a lot of things, but really hammered on simple and easy as focus points. If you give devs a place to store data outside the structure of the protocol... they will use it for all sorts of complicated craziness... which devolves to either multiple protocols, or a really complicated protocol.
I know his reasoning for it, I just disagree with him. People added JSON parsers that allow comments and can _still_ get tricky with them. The only thing the standard not adding them did was make sure we can't rely on them being there. And, for ANY file format that is used for config (and similar) that is supposed to be human readable, being able to add comments is pretty much table stakes imo.
> The only thing the standard not adding them did was make sure we can't rely on them being there.
I mean... that's basically the entire point of the decision. If you can't rely on them... you can't rely on them to ship metadata.
If you could rely on them to ship metadata... you start seeing parsers diverge wildly in features and scope - to the point that you've really got several different protocols all pretending to be "JSON". You end up with JSON_V1_UTF8_RTL, and JSON_V4_UCS2 and JSON_V3_EXT_UNICODE_LE, etc... All of which will be subtly (or not so subtly) incompatible, and then you're right back at XML.
No one is stopping you from writing config files in a superset of JSON that supports comments (yaml being the most common).
But the HUGE win here is that those formats are actually supersets - not alternative protocols. They all parse plain JSON. They might also happen to do tricky things - but if you give it standard JSON it works a-ok.
---
I think that there's an argument to be made that given how successful JSON is NOW - adding the ability to insert comments might be valuable (See: JSONC, or JSON5)
But I think as far as the initial stages went, not having comments was pretty clearly the right call.
Like - it's just a small step from comments to processing_instructions (ala XML: https://en.wikipedia.org/wiki/Processing_Instruction) and while I don't always agree with Crockford... I'm with him 1000% that the second you let that kind of metadata live in the format... the complexity EXPLODES.
Better to keep the standard format intentionally clean of it, and let people declare their own supersets.
There are a large number of people that consider that _not_ a benefit.