Why choose this over the other options? Just some thoughts: 1. I like that comments are part of the standard. I wrote my own C++ JSON parser that allows for co

Why choose this over the other options? Just some thoughts: 1. I like that comments are part of the standard. I wrote my own C++ JSON parser that allows for comments too. 2. Is it strict about indentation? One thing you can never get programmers to do on significantly sized teams is consistent indentation. Is that tab+space? Or spacex5? Is it going to break if a tab sneaks into Git? (Setting up Git push rules just annoys and confuses people.) 3. "without the syntatic clutter of JSON" - I happen to like it. I can compact it quite far if I need to. I also like the fact I can spit it out over a debug server and JS will just magically start reading it. 4. Something really cool would have been the introduction of typed data. One way we achieve this via JSON is to create a template file which would declare something like (in a file named 'template.json' or something): { "data" : { "type": "float", "default": 0.0, "min": -1.0, "max": 1.0 } } Obviously this requires checking in the code, but it does build up some kind of format checking and sanity. It can also warn you that it's using a default rather than a config defined value. It would be nice if there was then the ability to define type syntax... But I fear this might be going too far. 5. Another thing I do with JSON is inheritance. So you define a 'parent' property at the top of a file, the values are loaded from the parent and then the child loads theirs over the top. Why have this? We usually need some per-application configuration but mostly it stays the same. It saves having to write it multiple times. You can even break it down into sections to keep each configuration file smaller. (NOTE: For inheritance, a top tip is to implement "maximum depth", encase you get into a loop.)