I'd expand the list of quirks... JSON lacks comments (both line-level and block level). Fine for data transport but super super bad for configuration files.

Not that that matters when applications take it upon themselves to re-save the config file in some kind of normalisation effort. Bye-bye comments, hope they're checked in somewhere.

I'm lookin' at you, kubernetes...

But I'm curious what you mean by "in the wild"? If you're using (producing) it, something needs to consume it, and you would probably have control over both in whatever project you were using it for.

    {..., "birthday": "2018-03-25"}

So maybe we could do:

    {..., "birthday": "2018-03-25", "location": "Sydney/AU"}

   Year:
      YYYY (eg 1997)
   Year and month:
      YYYY-MM (eg 1997-07)
   Complete date:
      YYYY-MM-DD (eg 1997-07-16)
   Complete date plus hours and minutes:
      YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)
   Complete date plus hours, minutes and seconds:
      YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)
   Complete date plus hours, minutes, seconds and a decimal fraction of a second
      YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)
  where:

     YYYY = four-digit year
     MM   = two-digit month (01=January, etc.)
     DD   = two-digit day of month (01 through 31)
     hh   = two digits of hour (00 through 23) (am/pm NOT allowed)
     mm   = two digits of minute (00 through 59)
     ss   = two digits of second (00 through 59)
     s    = one or more digits representing a decimal fraction of a second
     TZD  = time zone designator (Z or +hh:mm or -hh:mm)

JSON5 is a good compromise.

For example,

  JSON.parse(`{"foo":"bar",}`)

This is a typo, I meant "can't" not "can". Off course browsers don't support JSON5 or my message makes no sense whatsoever.

{ "ConfigKeyComment": "This is for blah blah blah", "ConfigKey": "Foo" }

Obviously this wouldn't work in all cases (you're putting more work on your parser to interpret unused keys basically), but if we're talking config files specifically, I see this as an acceptable approach since there's little chance you'll be parsing such files more than once each (plus, writing a simple tool to strip the comments out would be very trivial).

    # Never enable this config, because if you do the space-time
    # continuum will collapse into itself and the cloud servers
    # will disappear in a puff of steam. However, if you really
    # must enable it, remember that it's boolean and go read
    # TICKET-8675309 for the extensive list of side effects.
    TurboFactorRenoberation = false
    

    {
        "ConfigKeyComment": "TICKET-8675309",
        "ConfigKey": "TurboFactorRenoberation",
        "ConfigVal": false
    }

Maybe I'm lazy but avoiding increasing cost to commenting is one of the few absolutes I abide by. Often I find myself tired after a long stretch of code, trying to convince myself that's it's understandable on it's own.

This is one of those systematic rules I have to enforce to shutdown my lazy lizard brain.

edit: But I can see how highly structured comments could actually come in handy as well for viewing configs in a gui

-Douglas Crockford, creator of JSON

There is no issue using JSON with comments for a config file.

/\/\/.*/gm

https://regexr.com/3rbgb

My point is only that this isn't a big issue. I don't understand why so many see it as a large issue. Instead, projects use non-standard YAML or other problematic solutions only because "JSON doesn't have comments".

    “_comment”: “blah blah blah”,

Personally I've found the exact opposite when dealing with 'normal' people. Most people can get basic YAML, but unless they're a programmers (or at least know how to program) most people fail miserably at writing JSON by hand.

Also detects repeated hash keys. This is a very good compromise between user-friendliness and machine-friendly specification and serialization.

Thank you very much for YAML! It is a critical user-interceptable interchange mechanism at several companies that I have worked at.

This has caused me so much misery in the past, especially since none of the tools will tell you which line the offending comma is on. Great, somewhere in my thousand-plus-line JSON file is a tiny syntax error but you won't tell me where.

Ended up having to regex for them. Didn't do wonders for my trust in JS tooling.

    python -m json.tool < somefile.json

There is also https://github.com/zaach/jsonlint

Intuitive usually means "close to what I'm used to".

Especially since leaving the trailing comma is considered the best practice in every other language.

The real schism here, IMO, is Programmer Intuitive vs. Natural Language Intuitive.

You misrepresented yourself by saying "object" when you meant "dict" and saying "practically identical" when you meant "vaguely syntactically similar". I wasn't trying to nitpick your semantics; I just had no idea that "Python objects are practically identical to JSON" meant "Python dicts are to Python what JSON objects are to JS, oh and also Python dicts have some syntactic similarlities to JSON" or whatever.