6 ms·

Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good e

Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good enough" even if it's stinky and it's also universally accepted that a small iteration on it with small conveniences doesn't make that much sense imho.

spicybright 5y ago
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.
snorkel 5y ago
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.
- colejohnson66 5y ago
  It would also make slightly nicer diffs
tootie 5y ago
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.
- kevinmgranger 5y ago
  That and any serialization format that has security implications is doomed to fail (or at least be derided).
  - mindless_solips 5y ago
    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."
    - kevinmgranger 5y ago
      What "fun surprises" does JSON have, aside from "the object could be arbitrarily big" ?
      - mindless_solips 5y ago
        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 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-beginners 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.
thayne 5y ago
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.
- throw0101a 5y ago
  > 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.
  - thayne 5y ago
    That's kind of my point. JSON5 is a much better for configuration than JSON.
  - moomin 5y ago
    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.
saurik 5y ago
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.
- spicybright 5y ago
  In practice, I've found most program configs allow comments and non quoted keys, for what it's worth.

spicybright 5y ago

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.

snorkel 5y ago

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.

colejohnson66 5y ago
It would also make slightly nicer diffs

tootie 5y ago

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.

kevinmgranger 5y ago
That and any serialization format that has security implications is doomed to fail (or at least be derided).
- mindless_solips 5y ago
  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."
  - kevinmgranger 5y ago
    What "fun surprises" does JSON have, aside from "the object could be arbitrarily big" ?
    - mindless_solips 5y ago
      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 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-beginners 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.

thayne 5y ago

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.

throw0101a 5y ago
> 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.
- thayne 5y ago
  That's kind of my point. JSON5 is a much better for configuration than JSON.
- moomin 5y ago
  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.

saurik 5y ago

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.

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