Comment by robert_tweed | Hacker News Reader

Comment by robert_tweed | Hacker News Reader

Parent Full thread

Funnily enough, as I've been experimenting with Chef and trying to stick to JSON config files where allowed, I was again struck that (a) it's not a good choice for config files (b) it's an OK choice though (c) lots of people are using it anyway (d) nearly everyone that does so (including Chef) allows comments, so in reality are not actually using JSON at all.

Point (d) is the important one. I really think we need a standard for json-with-comments. JSONC or whatever, but it should have a different standard filename and it should have an RFC dictating what is and isn't allowed. Personally I would allow only // comments because there are too many subtle issues with C-style comments, but it may be too late to agree on that.

Half the point of JSON is that if application A stores its data as JSON then application B can parse that without any nasty surprises. Except, there are now probably thousands of noncompliant implementations in the wild that only exist because the standard doesn't allow comments. Each one of those standards adds subtle differences (in addition to the comments themselves) depending largely on how they remove the comments before passing to the standards-compliant JSON parser (assuming they do that, which being DC's recommended approach, is as close to a standard as currently exists).

> (b) it's an OK choice though

I really think it's not an OK choice. A config file format that doesn't allow comments provides some of the worst possible UX.

One of the nice things about config files is that normally they are self-documenting, explaining the meaning of the various directives and providing possible values.

Without comments, you have to constantly switch between the documentation and the config file.

Also, the restriction on trailing commas is another really bad issue for a config file language as it pollutes diffs, makes moving lines around needlessly difficult and is one more landmine waiting to happen for the sysadmin editing a file.

No. JSON not at all OK as a config file language.

How does json "not support comments"?

{"comment":"default values for this object"}

Since when is in-band signalling a good idea? What if one of your configuration keys is named "comment"?

And what do you name your second comment?

{"notes to self":["Don't edit config files by hand","use a decent hierarchy"]}

//Http://jsoneditoronline.org

You could even write comments as a linear RSS feed of nested OPML outlines, by converting all that XML to JSON.

http://convertjson.com/xml-to-json.htm

Yep, I went through the process of replacing all our XML objects into json ones about 6 years ago now. Smaller files and much easier to read, manipulate store and transfer.

And while I personally quite liked XSLT, javascript is a much more flexible and reliable option.

For one thing, not every place where you might want a comment happens to be in an object.

Like where? Who for? For what purpose?

I cant think of a single example that this would be useful.

A list of items in an array. Some items in that list are of particular note.

(Say you have 15 items in an array. For whatever reason, such as you not being in control of the expected input structure of whatever you're giving this JSON to, you have them grouped with comments at the top of each block.)

Why would you want to do that in what is basically a human readable binary file and not in a readme?

You seemed to stop at the for who and for what purpose.

I can 'just' about see the case in something like nodeJS package.json files (that is the least of nodeJS's problems, but that's a whole other conversation). But a readme is a so much better option than having to troll through code comments.

The discussion above concerns why JSON isn't a good choice for configuration files. That's exactly because configuration files are not human readable binary files.

TBH. I find package.json files to be much much much much nicer files than configure.sh or settings.txt files, even a configure.py.

And if that isn't the case for you, not like you don't have the choice.

Did you miss the part where parent says he is using JSONC?

> I really think it's not an OK choice. A config file format that doesn't allow comments provides some of the worst possible UX.

Are we sure about that? E.g. mostly when messing with configuration files, I have to visit the documentation anyway, which could explain key-value pairs in the json file. Furthermore there are configuration files which consist mostly of comments to explain all kind of edge cases with actual configuration data commented, which can be a mess on its own.

If good code should be self-explanatory then why not configurations?

Reflecting the great tradition of "C++", I hereby propose calling it "//JSON".

We have had good luck with HOCON for config files:

https://github.com/typesafehub/config/blob/master/HOCON.md

JSON with comments? How about { "object":{ "foo":1,"bar":"New Jersey"} , "_comment": "blah blah blah" }

A bit hackish, but always worked for me.

Now add a comment for foo and another one for bar. Also try it when your client throws an exception whenever it encounters invalid keys in object. Or if perhaps it blindly persists or tries to perform some logic using that "data". And so on.

I like HJSON[0] for files you need to edit manually. You have comments and other user friendly things.

[0]https://hjson.org/

Reply on news.ycombinator.com