That's pretty ugly in practice.

A better solution is to use YAML for things like configuration files. It's more pleasant for a human than JSON would be even if it supported comments, and there are nice parsing libraries available for every popular language.

That's an ugly workaround, not a solution. It helps breed half-baked "solutions" like the "pipe through jsmin" Crockford himself suggests.

Ultimately, it makes JSON unsuitable for configuration files (there are other reasons for that, to be fair, like over-verboseness)

Not necessarily. If you're naming your keys nicely, and using an easily-understandable structure, for simple config files, you shouldn't really need comments.

"simple config files" implies an optimist. Good for you, sir.

Yes, that solution OBVIOUSLY removes the need to spend an extra minute adding comments to the spec.

Also, I hope, trailing commas and binary types.

Shoving binary into JSON is rather silly--base 64 encode it, or consider using a binary format better suited to your need.

As for adding comments to the spec--again, the idea is to prevent shadow information showing up that isn't obvious to a conformant parser.

If you give people the ability to smuggle data in comments, that's exactly what they'll do. At least this way people know that what they're doing isn't "to spec" and that their sneaky parsers are not following the rules.

I mean, JSON itself is rather silly in that it's a horrible serialization language. Its main boon is its C-style syntax, which is why it's so readable to all of us who read similar syntaxes all day. Even just a syntactical change noting which strings were base64 encoded would be nice.

It takes a minute to add anything to a spec. It increases the cost of implementing the spec a lot more than a minute though.