The problem with not using JSON is that the alternative almost always is "some proprietary format" or "an undefined dialect of something that looks like a well-

The problem with not using JSON is that the alternative almost always is "some proprietary format" or "an undefined dialect of something that looks like a well-known format". I consider that significantly worse. With JSON, you at least can assume that the person reading it will understand what the file means. With a proprietary format, especially the popular "key=value" format, it gets super murky - what are the rules for quotes in this dialect (are quotes required, optional, or interpreted as part of the value, which escape characters), will white space be included, etc. Lack of comments does seem like a very valid point. I don't see the issue with readability. It is not great but still OK without syntax highlighting, and superb with highlighting (which works because it's a wide-spread standard format, not some weird custom dialect). The strictness is mildly annoying, but violating it will make the config obviously invalid, which means it can be rejected instead of silently breaking production because you used a single quote and this dialect's parser only considers double-quotes, so your single quote was considered part of the string. I don't know of many projects that use programmable configs, and many attempts to achieve this resulted in horrendous nightmares. Seems like a superset of JSON that remains a subset of JS (like JSON5) can address most concerns, and can still be syntax-highligted with a JS highlighter.