And XML is a very battle-tested alternative that supports every conceivable edge case and arbitrary depths of strictness and validation. There was soooo much energy poured in to making XML the One Format To Rule Them All. It has so many advanced features like strict definitions, includes syntax, support for mixed content, entities and references, comment syntax. But it turns out that 99% of users never needed any of that and just wanted nested key-value pairs.

That and any serialization format that has security implications is doomed to fail (or at least be derided).

What?!? BREH, read Effective Java on Serialization.

Every serialization format has security implications.

Some try to make this explicit and probably fail in capturing all conceivable holes. Some leave this implicit to give you "fun surprises."

What "fun surprises" does JSON have, aside from "the object could be arbitrarily big" ?

A serialization format is more than just how things are described on the wire. It's also about how both sides are expected to receive and transmit it. Naive processing of JSON in certain situations can run into sharp edges like this:

https://rules.sonarsource.com/java/RSPEC-4544

Serialization formats are a part of Protocols, which essentially form the software equivalent of a spoken language between two people. Like words, the bytes can have a general syntax and expected semantic, but still be open to problematic interpretation. Like the conceptual difference between a language like English and Ithkuil. (http://www.newyorker.com/magazine/2012/12/24/utopian-for-beg...)

Like Ithkuil, some formats can specify "a little more" in a way that tries to prescribe semantic meaning and syntax such that implementing according to spec limits the opportunities for issues like this to happen.

JSON is "good enough" for a textual, mostly human readable data interchange format. But as a configuration format, for example the package.json file for node/npm/yarn, it is most definitely not "good enough". For two reasons: no comments and no multiline strings. The latter might not be important for some types of configuration, but it is for things that need something like a description that is more than a single sentence.

> But as a configuration format, for example the package.json file for node/npm/yarn, it is most definitely not "good enough".

Then perhaps don't use it for a use case it was not designed to address? I understand that JSON is a very handy hammer to have, but not all things are nails.

I mean, that’s all very well, but it’s literally one of only two formats with native support in the browser. So there’s plenty of times you don’t really have any choice other than to hammer that screw in.

That's kind of my point. JSON5 is a much better for configuration than JSON.

It is just that people keep insisting on using JSON for human-maintained configuration files, and JSON sucks for that: no comments, trailing commas, or multi-line strings.

Since JSON5 is trivially pre-processed into JSON, it tends to be useful as a tack-on to such projects to let your startup scripts generate the real file given the useful on without having unrelated syntax.

In practice, I've found most program configs allow comments and non quoted keys, for what it's worth.

If I had to pick one feature add, it’d be allow trailing commas. That would make serializing a bit easier and less error prone.

It would also make slightly nicer diffs

It's true. I doubt this spec will pick up even a little traction either since it's not backwards compatible.

You trade slightly more concrete data structures for hard incompatibility.

Maybe an internal api could leverage this in some way?

But it really isn't that hard to wrap hex, floating points, etc. in quotes and parse that server side.

Any application that's not a pet project should be using json schemas anyways, which is the layer you could put your custom datatypes into.