Hacker News Reader

Comment by curtis3389 | Hacker News Reader

Because noone wants to dump a ton of work into a JSON parser they can't say is standards-compliant because it also supports C-style comments?

View on HN

Hm it is interesting that your hypothesis is solely the exclusion of comments from JSON. I can understand the constraint when you consider JSON as a data transmission spec rather than a configuration spec.

I also find TOML to be much a cleaner syntax than either of the two, but maybe we should just give up and make a JSON-C (for Configuration, I just made this) which supports comments.

FWIW, JSON5 and Hjson share those goals.

https://json5.org/

https://hjson.github.io/

Or just use TOML when it's appropriate; that's what I do, and I haven't had cause to regret it.

One can usually answer the question "am I going to frequently have deeply-nested tables and/or long strings for keys" in advance, and if the answer is no then TOML is practically ideal. If it proves to be wrong occasionally than JSON is a reasonable fallback, as is just coping with the verbosity of TOML.

See JWCC (JSON With Commas and Comments) https://nigeltao.github.io/blog/2021/json-with-commas-commen...

I'm not sure if it comes from a plugin or not, but that's one of the options I have in VSCodes language dropdown, JSON with comments, and it's exactly what the name says, it's json, but it doesn't die on // style comments. It also kicks in if I name the file with .jsonc as the extension.

Reply on news.ycombinator.com