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.
