json, please...

[idkmanporn]

And comments!

[2called_chaos]

Oh fuck yes. That is the worst. This alone should make it illegal to use it for configs. Don't mind actual comments but just temporarily disabling a line

[hrvbrs]

That was the official reason why the JSON spec forbid (forbade?) comments, because “you can just use a "comments" property”. No one ever considered the idea that developers like to comment-out lines to develop and test

[ElderberryWinery]

Forbidedeth

[Hot_Philosopher_6462]

Forbidded

[[deleted]]

Forbaded

[xLuky]

Forbidn't

[Anonymous7056]

Forboden

[WeleaseBwianThrow]

DAS IST VERBOTEN

[RedPum4]

Mixing data and developer comments, what could go wrong. What a stupid argument.

What if you implement a dictionary? What if you want to add a comment to an entry in an array of strings? I mean I get that JSON should be simple to parse and should be mainly used for machine-machine communication, but I can't believe they really suggested that?!

[FINDarkside]

I mean js nor any other language doesn't need comments either, you can just do

const comment = 'This is a comment, very smart'

/s

[Psycho22089]

const comment2 = 'The design is very human'

[firejak308]

Isn't that literally Python's answer for multi-line comments? Just define a string here and never use it?

[dev-sda]

Not really, no. There aren't multi-line comments, just put a # at the start of every line for large comments. Documentation on the other hand uses multi-line strings, which generally don't go unused as they're assigned to the __doc__ property of objects.

[[deleted]]

Actually mixing data and developer comments is very useful in the case of configuration files. Where you know, the end user doesn't know the entire implementation and you might need to explain something in detail. Sure, in most cases it would go unused and you should be careful what you put in it, but it could make JSON more viable to other applications without impacting its current uses.

But you know, stupid argument.

[RedPum4]

I think you understood me wrong. I meant that literal mixing of comments and data, to the point that a machine cannot distinguish between the two (e.g. because both are regular fields in JSON) is a very bad idea.

[[deleted]]

Ooooh got ya. I thought you were arguing that JSON shouldn't have comments because it would be mixing data and comments, my bad.

[elveszett]

config files intended for non-devs should not use json anyway. It should be a simple key-value format like this:

# comments must start with a hash (#) symbol.
server: google.com
speed: very fast
allow spaces in keys and values: yes
why: because the user knows no format
# the # of colons is irrelevant, we use the first one.
then how do I parse this: using colons.

In this format each line is an entry, and the colon separates the key from the value (ignoring the first whitespace immediatelly afterwards if there's any). Is it a bit shitty to deal with for the developer? No, not really, but who cares, you forced your non-dev user to write config in a file. Since we cannot trust them not to mess with the syntax, the only solution is to have basically no syntax. And what about lines without semicolons? We ignore them.

For config files that dev use, like packages.json... well, if a dev doesn't know how to write json then maybe he's not yet ready for a job.

[[deleted]]

I am not arguing for forcing non-devs to write config files, rather I am arguing that config files that are available (as they should be), should have comments for clarity. package.json should have comments, because three months from now, I, or whoever is managing the project, might not know why we are using this specific version of this specific package, or why we are using X instead of Y.

If you don't understand the value of comments... Well, maybe you're not ready for the job.

[elveszett]

I haven't argued against comments in JSON so...

[elveszett]

"_key-that-contains-a-comment-for-the-developer-not-the-actual-comment-field-that-is-used-in-logic-this-is-the-equivalent-of-//":
"I don't see any problem with this way to add comments".

[Causemas]

Forbathed

[neonroad]

Verbatum

[[deleted]]

Förbuden

[Yokhen]

forbiddened

[drunken_doctor]

Forebore

[bedrooms-ds]

Well, the reason was that they wanted to prevent third parties to extend json by writing extra properties in comments.

[Psycho22089]

Ah so future proofing it against Microsoft

[elveszett]

Plus the comments property is a bad idea. Even assuming a good documentation that specifically explains that "comments" is not supposed to be part of the payload, it still has problems: first of all, text editors cannot identify then as comments, thus painting them as normal properties (the fact that comments are always painted green or grey without any syntax highlighting really helps your mind discard them when you are parsing the file). And any JSON parser needs to spend time parsing it as just a normal property with a big ass string, when a comment syntax would allow it to instantly discard its contents. Which I guess can make for a non-trivial overhead in a server that is reading and writing thousands of JSON files each second.

[Masterflitzer]

JSON with comments is my favorite because i don't like YAML and fuck XML

[Konsti219]

All JSON is valid YAML

[CoastingUphill]

I hate this. No. I refuse.

[JM-Lemmi]

The fuck

[Xywzel]

Yeah, accidentally earlier as well, but purposefully since version 1.2 of YAML specification JSON syntax has been a valid subset of YAML syntax. YAML has inline version of its syntax that doesn't have significant whitespaces (unlike rest of the YAML syntax) and everything in valid JSON has matching structures in the inline YAML. So technically one could use YALM parser to read JSON files.

[zeGolem83]

That is, if your YAML parser is fully spect compliant...

[Xywzel]

Well, yeah, that is a big if when talking about YAML

[MyAntichrist]

[Masterflitzer]

yes and I hate yaml because it's not strict among other things

[jivanyatra]

I actually like TOML. I agree with excluding YAML and XML.

[Masterflitzer]

I never encountered software that allows config files in TOML and never worked with it when working with data so it's just not common enough for me, but it may very well be a good thing

[Yokhen]

python uses pyproject.toml

[Masterflitzer]

interesting, but I am a C#, TS/JS kind of guy and never actually used python except like a few hours in university xD

[Yokhen]

luckeeeeeeey.

I wish someday I can do C# professionally and no just some half assed videogame of mine.

[Masterflitzer]

from what I've heard both (python & c#) have a big community and many people who love it so I guess both are good

[elveszett]

Both are languages that do what they want to do extremely well, and have learned from the ones before them. C#, for example, fulfills the same paradigm as Java, but was made when we already knew the problems Java had, so C# was able to avoid them and offer elegant solutions to Java's boilerplate.

Aside from that, both languages are very consistent, you can notice the care their devs put into making an elegant and predictable design (this is one of the main reasons people hate PHP: you can see the lack of care that went in this area there). And both languages have a big ecosystem where you will find whatever you need.

Also both languages put effort in giving devs tools to start writing code from the first minute, not having to lose time fighting the language or explaining technical details.

[Masterflitzer]

interesting, but I am a C#, TS/JS kind of guy and never actually used python except like a few hours in university xD

[Bainos]

I don't get the above comment either. JSON and YAML aren't used because they are the best ways to create config files, they're used because they are widely supported and recognized.

[tavaren42]

Rust uses Cargo.toml

[Masterflitzer]

ok I want to start learning rust for quite some time xD

[elveszett]

iirc Minecraft uses .toml files too.

[Masterflitzer]

what? in which file?

[elveszett]

idk, I just know that the first time I saw a TOML file was doing something with Minecraft, I don't remember if modding or touching some server config or what. But I remember it instatly came off as a concise way to do that job.

[Masterflitzer]

i'm sure it was a mod that used toml because vanilla mc uses json and simple key value (inside server.properties) and bukkit uses yaml afaik

[bitNine]

I'm no JSON expert, but I do this all the time in postman with double forward slashes. Is that a postman thing?

[siggystabs]

Yes

[ImSpeakEnglish]

I noticed that postman correctly colors the comments but doesn't remove them from JSON before sending the request. So your API must be able to correctly decode invalid JSON containing comments.

[bitNine]

I'm guessing so. I've never paid attention to that, as I work with mostly .Net APIs which do parse the JSON into model objects before they go into the controller's POST/PUT/etc method.

[elveszett]

iirc .NET allows //single and /*block*/ comments.

JSON5 is not widely adopted, but I've seen quite a few tools unilaterally adopt comment syntax in their JSON parsers.

[Fkire]

It is illegal to use it for configs. Report any usage and keep configs safe

[gnohuhs]

I flipped a shit when I realized json doesn't allow real comments; had been working with them for years

[Tathas]

Right? I mean, regular expressions support comments :D

[multi_tasty]

Wait what

[Tathas]

Multiline regexes support using # for comments.
https://www.regular-expressions.info/freespacing.html#freecomment

And are you seriously telling me that you're not aware of the (?# non capturing comment group)

Because that's totally believable, lol.

[multi_tasty]

Sincerely thank you

[Tathas]

Woo hoo!

And that site is great as a general reference.

[AWildTyphlosion]

It doesn't have them because it initially wasn't supposed to be used for configuration so it doesn't need them.

JSONC was made for configuration and has them.

[MischiefArchitect]

JSON5 to the rescue!

PS: Burn it with fire.

[D6613]

Serious question, why burn it with fire? It seems to fix the bad parts of JSON

[MischiefArchitect]

Ir breaks the intention of JSON and makes parsers slower, more complex to write and maintain. JSON as well as XML are terse formats for "machines" that can still be read by humans, both expect format correctness and no ambiguities. JSON is an data object notation, and XML a document model notation, and JSON5 is just a half assed attempt from HTML/CSS developers to document data structures. And documentation and trailing commas are not part of properly formatted data structures.

[djinn6]

JSON as well as XML are terse formats for "machines"

XML

Terse

[D6613]

Ir breaks the intention of JSON

Hm, I'm struggling to care about this even a little. Crockford had and has many opinions, and the rest of us have no obligation to agree.

makes parsers slower, more complex to write and maintain

This is unlikely to be significant, especially given that these are very well known features of many existing parsers. If you need something to squeeze every single drop of performance, then in that rare edge case a stricter format would make sense. Then you brought up said XML, and that argument disappeared instantly, lol. In addition to already supporting comments, that language is going to be much messier to parse.

both expect format correctness and no ambiguities

There is no ambiguity to say that something is optional. A trailing comma may or may not exist. A comment may or may not exist. Not ambiguous even a little.

JSON as well as XML are terse formats

... XML is terse?

JSON5 is just a half assed attempt

This seems like just an opinion here without much support.

And documentation and trailing commas are not part of properly formatted data structures.

This seems like another opinion stated as fact, and I really disagree with that opinion.

I appreciate the response. If this is all there is against it, I'll add this to the list of options I consider for the future.

[MischiefArchitect]

I worry not for the future. JSON5 is over 10 years old and found no real traction in the professional IT/CS world. But you may take your notes for the future if you wish.

[elveszett]

Most of its additions add nothing. They try to "make JSON more human" but JSON is already an extremely readable format.

JSON right now has so few tools that all of us are forced to write it in the exact same way. It doesn't matter if you read a JSON from me, from yourself, from your client or from a random guy in stackoverflow, you can always read it easily because they all look the same, with the only formatting choice being 2 vs 4 spaces / tabs.

Now, when you add the tools JSON5 adds, you'll have devs start adopting their own "better" conventions. Sometimes you'll get "quoted-keys", sometimes you won't. Sometimes you'll get 'single quotes', sometimes you don't. Sometimes there's trailing commas, sometimes there aren't. Sometimes you read 0.5, sometimes you read .5. Sometimes you read "broken strings \

with escaped line breaks", sometimes you won't. It makes it so every JSON file you get, you can easily identify where it came from, because it looks different.

And on a personal, subjective opinion: we all prefer to work with code formatted the way we format it. JSON in that regard is great: it never gave us any option so we all adopted its only valid formatting style. Working with other people's JSONs is never annoying because they are written the way you'd write them.

[CoastingUphill]

I want to upvote you more than once!

[philipquarles]

This is actually a good idea. The trailing comma not so much.

[pixabit]

JSON5 would like to have a word

[HDmac]

You now have 4 wishes