3 ms·

I think JSON would be vastly improved if it were to just allow comments. Maintaining configuration in JSON is unnecessarily painful due to this pointless featur

I think JSON would be vastly improved if it were to just allow comments. Maintaining configuration in JSON is unnecessarily painful due to this pointless feature gap.

reificator 7y ago
While I agree, that seems off-topic and it comes up most every time issues with JSON are brought up. I found this to be a rather interesting article, and it'd be a shame if the discussion around it centered on such a well-tread topic.
frenchy 7y ago
If you're maintaining a configuration file in JSON format, you're using the wrong tool for the job. I know a certain popular package manager does exactly this, but popular doesn't necessarily mean well designed.
DonHopkins 7y ago
It wasn't an arbitrary decision, there's a hard reason: round-trip format conversion. https://en.wikipedia.org/wiki/Round-trip_format_conversion https://en.wikipedia.org/wiki/Round-trip_format_conversion The reason JSON can't support comments the way XML does, is that comments aren't part of the JavaScript "DOM". They disappear when you parse them, so they can't round-trip, and there's now way to stringify comments back out. Standard XML parsers and XML/HTML DOM APIs give you all the comments and whitespace, and it's up to you to ignore them if you don't care, and they're not lost when you parse and re-serialize. Comments and whitespace are part of the standard DOM/SAX API, but you can't just nail those onto another model like JavaScript polymorphic objects/arrays after the fact. Because parsed JavaScript objects and JSON structures provide no way to access the comments the parser threw away. Although of course you could implement a parser that saved the comments, but it would need to support another more complex API than directly accessing JSON objects, which could somehow describe where each comment was in relation to the parsed object (since multiple comments can appear anywhere), and what kind of comment it was (// or /* */), as well as where all the whitespace the parser ignored was. (Although XML parsers typically don't tell you about whitespace inside of tags, so that can't round-trip.) That is theoretically feasible with a JSON API implemented from the ground up in any language, like JSON.Net for example. But it's not practical in JavaScript itself (or Python or any language that parses JSON into pre-existing polymorphic arrays and objects), because you parse JSON into actual JavaScript (or Python) objects, whose API and implementation isn't under your control. So JSON being able to round-trip with any language other than JavaScript (and Python) itself would have been silly. JSON would not be as powerful and useful a format if parsing then serializing JSON lost information. JSON was meant to be a round-trippable format, so there was no other choice but to leave out comments. But maybe there's a use case for a "lossy" compressed JSON format like JPEGSON. ;) https://en.wikipedia.org/wiki/Lossy_data_conversion https://en.wikipedia.org/wiki/Lossy_data_conversion

I think JSON would be vastly improved if it were to just allow comments. Maintaining configuration in JSON is unnecessarily painful due to this pointless feature gap.

reificator 7y ago

While I agree, that seems off-topic and it comes up most every time issues with JSON are brought up. I found this to be a rather interesting article, and it'd be a shame if the discussion around it centered on such a well-tread topic.

frenchy 7y ago

If you're maintaining a configuration file in JSON format, you're using the wrong tool for the job. I know a certain popular package manager does exactly this, but popular doesn't necessarily mean well designed.

DonHopkins 7y ago

It wasn't an arbitrary decision, there's a hard reason: round-trip format conversion. https://en.wikipedia.org/wiki/Round-trip_format_conversion https://en.wikipedia.org/wiki/Round-trip_format_conversion The reason JSON can't support comments the way XML does, is that comments aren't part of the JavaScript "DOM". They disappear when you parse them, so they can't round-trip, and there's now way to stringify comments back out. Standard XML parsers and XML/HTML DOM APIs give you all the comments and whitespace, and it's up to you to ignore them if you don't care, and they're not lost when you parse and re-serialize. Comments and whitespace are part of the standard DOM/SAX API, but you can't just nail those onto another model like JavaScript polymorphic objects/arrays after the fact. Because parsed JavaScript objects and JSON structures provide no way to access the comments the parser threw away. Although of course you could implement a parser that saved the comments, but it would need to support another more complex API than directly accessing JSON objects, which could somehow describe where each comment was in relation to the parsed object (since multiple comments can appear anywhere), and what kind of comment it was (// or /* */), as well as where all the whitespace the parser ignored was. (Although XML parsers typically don't tell you about whitespace inside of tags, so that can't round-trip.) That is theoretically feasible with a JSON API implemented from the ground up in any language, like JSON.Net for example. But it's not practical in JavaScript itself (or Python or any language that parses JSON into pre-existing polymorphic arrays and objects), because you parse JSON into actual JavaScript (or Python) objects, whose API and implementation isn't under your control. So JSON being able to round-trip with any language other than JavaScript (and Python) itself would have been silly. JSON would not be as powerful and useful a format if parsing then serializing JSON lost information. JSON was meant to be a round-trippable format, so there was no other choice but to leave out comments. But maybe there's a use case for a "lossy" compressed JSON format like JPEGSON. ;) https://en.wikipedia.org/wiki/Lossy_data_conversion https://en.wikipedia.org/wiki/Lossy_data_conversion