> The only thing that JSON is really missing are comments and trailing commas.

The reason JSON doesn't have comments [1]:

    I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.

    Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

JWCC literally stands for JSON With Commas and Comments.

JWCC is also what Tailscale call HuJSON, as in "JSON for Humans", which as amusingly also what json5 claims to be.

https://github.com/tailscale/hujson

Exactly! Trailing commas (for cleaner commits) and comments are the only pain points I ever felt.

On the other hand:

> leadingDecimalPoint: .8675309

This is just lazy. Can we discuss in depth how much time you saved by skipping the “0” in favor of lesser readability?

> andTrailing: 8675309.,

This doesn’t mean anything to me.

As a data guy I find myself running into JSONL a fair bit. It was surprising to me that it’s not supported in the vanilla spec.

JSONC is fine but VCS should have named its configuration files settings.jsonc since the files are not JSON and will not be parsed by JSON parsers.

> The only thing that JSON is really missing are comments and trailing commas. I use JSONC for that.

YAML[0] supports JSON formatted resources and octothorpe ('#') comments as well. I didn't see anything in the spec specifically allowing for trailing commas however.

Here is an exemplar using the Ruby YAML module:

  #!/usr/bin/ruby
  
  require 'yaml'
  
  
  puts YAML.load(
    %/
      # YAML is a strict superset of JSON, which
      # means supporting octothorpe end-of-line
      # comments is supported in JSON formatted
      # YAML if and only if the content is multi-line
      # formatted as well (like this example).
      {
        # This is valid YAML!
        "foo" : "bar"
      }
    /
    )
  

Also take a look at ASON [1]. ASON is a data format that evolved from JSON, introducing strong data typing and support for variant types.

[^1] https://github.com/hemashushu/ason

> The only thing that JSON is really missing are comments and trailing commas.

And multi-line strings. You don't always need that, but when you do, it's absence is very painful.

Allowing for leading decimals without a preceding zero also seems like shifting a whole class of errors right.

I'm not a fan of forcing single or double quotes because escape codes are such a pain to deal with and to me make things significantly harder to read than an inconsistent quoting style ever could.

I just add another property with noncolliding name as a comment.

"//key":"this is here so that foo bars", "key":"value",

valid JSON. Most software handles extra propertiesjust fine

> the only thing that JSON is really missing

Depending what you use JSON for, "Numbers may be IEEE 754 positive infinity, negative infinity, and NaN." could be a huge plus.

> The only thing that JSON is really missing are comments and trailing commas. I use JSONC for that. It's what VSC uses for the config format and it works.

I disagree. Human-friendy multiline strings aren't really optional for a serialization format that will inevitably also be used as a config format sometimes because those are the same problem.

The choice of single vs double quotes means you can use single quotes if the contents contain a double quote and vice-versa. With JSON containing shell scripts (looking at package.json scripts) that's a valuable addon imo.

Someone just needs to write “JSON5: The Good Parts” and an aggressive linter to enforce it.

JSON only allowing double quotes is something I have grown to not care about, but as someone that was using JavaScript object literals before JSON became a thing, I confess I do not understand why it is an advantage? If you were at a place where it was a heavy discussion on what quote to use, I'm forced to think there were deeper cultural issues at play?

Don't get me wrong, the ubiquity of JSON speaks for itself and is the reason to use it. But, to say it has tangible benefits feels very dishonest.