5 ms·

I wish JSON had 1) trailing commas 2) comments (I'm not sure if this is a good idea or not but every once in a while I impulsively write comments)

kanobo 6y ago
It's funny I have the opposite feeling. In my case I write a formatter/validator in each project for my json that fixes issues like trailing commas and is also where I annotate the data structure, but I can imagine for those who write JSON by hand those two limitations would be a headache.
tgb 6y ago
I just wish it supported all floats (nans and infinities too).
- nitrogen 6y ago
  An integer datatype would also be very useful. 53 bits isn't always enough.
  - jolmg 6y ago
    The format doesn't have any set limit. Rather, it's implementations that set a limit. Ruby's standard JSON parser returns values of class Integer for integers in the JSON.
abraxas 6y ago
3) set types, 4) optional schemas 5) multiline strings 6) consistent support for numeric types 7) streaming data The litany is not short and I'm sure I've overlooked a couple.
- selectnull 6y ago
  8) date types
- speedgoose 6y ago
  You can try json schema. Streaming data is also easy with json lines. But if you add too many features, it may end up like XML.
  - abraxas 6y ago
    yeah, you can do everything by imposing more topology on top of JSON just like as it happened with XML. The JSON advocates are slowly reinventing everything that their parents built into XML 20 years earlier. My hunch is that it will share its path in acquiring bloat.
    - mianos 6y ago
      From what I have seen, the excessive topological frameworks on top of JSON have never really take off. There have been many schema systems available for 10 years now but for some reason everyone seems to fall back to accepting basic JSON. There is a place for this stuff but only in very limited areas. Hopefully it does not go too far, for example like Microsoft did with SOAP. I still have nightmares from work decoding completely wrong XML generated by the native SOAP XML generators in old C# banking apps.
- austincheney 6y ago
  JSON is popular because it’s tiny. If you want to trade tiny for a litany of features and data types then just use XML.
- aloisdg 6y ago
  You should try XML. You may like it.
  - KiwiJohnno 6y ago
    That reminds me of my favourite XML quote: "XML is a lot like violence. If it isn't solving your problem, then you aren't using enough of it"
    - bfuclusion 6y ago
      JAXB is at the same time awesome, and completely terrifying.
- emil0r 6y ago
  So basically EDN.
  - abraxas 6y ago
    Right
- throw0101a 6y ago
  > 4) optional schemas Perhaps CDDL: * https://tools.ietf.org/html/rfc8610 https://tools.ietf.org/html/rfc8610
- user5994461 6y ago
  What do you mean by schema? JSON supports schema with libraries included in most popular languages nowadays. https://json-schema.org/ https://json-schema.org/ For numeric types, if you handle integer larger than 2 billions or floating numbers where the precision is critical (that's where json fails), these can and should be represented as string. I don't think there is any common format that guarantees large numbers and/or arbitrary precision to be encoded and decoded properly across languages and platforms.
seagreen 6y ago
Comments are a great idea... for a configuration format! They're really bad for a data interchange format though, because people inevitably start putting important data in them and you end up with two different ways to write strings, one of which isn't supported by every parsing library. Thus each discussion of JSON ends up being two groups talking past each other, the people using it as a configuration format who lament the lack of comments, and the people using it as a data interchange format who celebrate it. The solution: since it's too late to add comments now, don't use JSON as a configuration format.
- Tokkemon 6y ago
  So Yaml?
  - seagreen 6y ago
    YAML's way, way more complicated that JSON. To pick one rough measure, the spec is about 7x as long. It includes a bunch of things that could be seen as negatives, such as nine(!) different ways to write multi-line strings (https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-over-multiple-lines/21699210#21699210 https://stackoverflow.com/questions/3790454/how-do-i-break-a...). I don't have a single competitor to recommend, but JSON5, TOML, JSONC (mentioned in a sister comment), or something else along those lines might be better. I'd probably just go with whichever of those is popular in your community.
    - mpfundstein 6y ago
      i really like hashicorp hcl. more than json. (and yaml is TERRIBLE)
      - andybak 6y ago
        YAML might be terrible for the reasons given elsewhere but I really want something YAML-like (maybe TOML, maybe something else) For me, readability is king both for myself and because I sometimes want non-developers to be able to hand-edit files. Any curly brace format is a non-starter. Too much clutter, too easy to create invalid files that aren't obviously invalid at a glance. Significant white space does have the advantage of meaning exactly what it appears to mean and being intuitively understandable to most people.
Tokkemon 6y ago
Yes, definitely. Every time I work with PHP Arrays, I'm reminded both these things don't exist in JSON and it makes me sad.
dhbradshaw 6y ago
The other day I saw an auto-generated json file with comments and trailing commas and got really excited. A little digging showed that it was using JSON5. Pretty sweet! https://json5.org/ https://json5.org/
- divbzero 6y ago
  Cool! JSON5 looks intriguing. The core project implements a JavaScript module [1] but it looks like there are also experimental JSON5 libraries for Go [2], Python [3], Ruby [4], and Rust [5]. [1]: https://www.npmjs.com/package/json5 https://www.npmjs.com/package/json5 [2]: https://github.com/yosuke-furukawa/json5 https://github.com/yosuke-furukawa/json5 [3]: https://pypi.org/project/json5/ https://pypi.org/project/json5/ [4]: https://github.com/bartoszkopinski/json5 https://github.com/bartoszkopinski/json5 [5]: https://docs.rs/json5/ https://docs.rs/json5/ I noticed that JSON5 doesn’t include a Date type. There have been discussions about this in both the JavaScript [6] and spec [7] repos but with no resolution yet. [6]: https://github.com/json5/json5/issues/3 https://github.com/json5/json5/issues/3 [7]: https://github.com/json5/json5-spec/issues/4 https://github.com/json5/json5-spec/issues/4
  - divbzero 6y ago
    What would really help JSON5 take off is if it gets bundled with browsers by default. For now it doesn’t seem all that appealing to add <script src="//unpkg.com/json5/dist/index.min.js"></script> to every HTML page as extra JavaScript instead of a native browser implementation.
smabie 6y ago
HOCON solves pretty much all the problems JSON has, including the ones you mentioned.
throw0101a 6y ago
> 2) comments Per Douglas Crockford, the creator of JSON, comments were an anti-feature: > 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. * https://web.archive.org/web/20120507093915/https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr https://web.archive.org/web/20120507093915/https://plus.goog... Discussion on the post (2012): * https://news.ycombinator.com/item?id=3912149 https://news.ycombinator.com/item?id=3912149 Remember: JSON was designed primarily as a data exchange format between computers.
- MichaelMoser123 6y ago
  Processing instructions can always be added as a special name value entry, that wouldn't be a good reason to get rid of name value pairs
- enricozb 6y ago
  This is what I figured would be the reason to remove comments, because they would hold some other non-human information. It's unfortunate that people do this. The main reason for comments for me would be for config files, which maybe shouldn't be in JSON anyways.
  - throw0101a 6y ago
    > The main reason for comments for me would be for config files, which maybe shouldn't be in JSON anyways. I think this is a bit of 'over reach' in what JSON was intended to do, so it's perhaps not surprising that there may be some things 'lacking' for that purpose.
user5994461 6y ago
There you go json for humans https://hjson.github.io/ https://hjson.github.io/ This allows trailing commas and comments. This can also reads strict json of course. Libraries are available for all popular languages.

kanobo 6y ago

It's funny I have the opposite feeling. In my case I write a formatter/validator in each project for my json that fixes issues like trailing commas and is also where I annotate the data structure, but I can imagine for those who write JSON by hand those two limitations would be a headache.

tgb 6y ago

I just wish it supported all floats (nans and infinities too).

nitrogen 6y ago
An integer datatype would also be very useful. 53 bits isn't always enough.
- jolmg 6y ago
  The format doesn't have any set limit. Rather, it's implementations that set a limit. Ruby's standard JSON parser returns values of class Integer for integers in the JSON.

abraxas 6y ago

3) set types, 4) optional schemas 5) multiline strings 6) consistent support for numeric types 7) streaming data The litany is not short and I'm sure I've overlooked a couple.

selectnull 6y ago
8) date types
speedgoose 6y ago
You can try json schema. Streaming data is also easy with json lines. But if you add too many features, it may end up like XML.
- abraxas 6y ago
  yeah, you can do everything by imposing more topology on top of JSON just like as it happened with XML. The JSON advocates are slowly reinventing everything that their parents built into XML 20 years earlier. My hunch is that it will share its path in acquiring bloat.
  - mianos 6y ago
    From what I have seen, the excessive topological frameworks on top of JSON have never really take off. There have been many schema systems available for 10 years now but for some reason everyone seems to fall back to accepting basic JSON. There is a place for this stuff but only in very limited areas. Hopefully it does not go too far, for example like Microsoft did with SOAP. I still have nightmares from work decoding completely wrong XML generated by the native SOAP XML generators in old C# banking apps.
austincheney 6y ago
JSON is popular because it’s tiny. If you want to trade tiny for a litany of features and data types then just use XML.
aloisdg 6y ago
You should try XML. You may like it.
- KiwiJohnno 6y ago
  That reminds me of my favourite XML quote: "XML is a lot like violence. If it isn't solving your problem, then you aren't using enough of it"
  - bfuclusion 6y ago
    JAXB is at the same time awesome, and completely terrifying.
emil0r 6y ago
So basically EDN.
- abraxas 6y ago
  Right
throw0101a 6y ago
> 4) optional schemas Perhaps CDDL: * https://tools.ietf.org/html/rfc8610 https://tools.ietf.org/html/rfc8610
user5994461 6y ago
What do you mean by schema? JSON supports schema with libraries included in most popular languages nowadays. https://json-schema.org/ https://json-schema.org/ For numeric types, if you handle integer larger than 2 billions or floating numbers where the precision is critical (that's where json fails), these can and should be represented as string. I don't think there is any common format that guarantees large numbers and/or arbitrary precision to be encoded and decoded properly across languages and platforms.

seagreen 6y ago

Comments are a great idea... for a configuration format! They're really bad for a data interchange format though, because people inevitably start putting important data in them and you end up with two different ways to write strings, one of which isn't supported by every parsing library. Thus each discussion of JSON ends up being two groups talking past each other, the people using it as a configuration format who lament the lack of comments, and the people using it as a data interchange format who celebrate it. The solution: since it's too late to add comments now, don't use JSON as a configuration format.

Tokkemon 6y ago
So Yaml?
- seagreen 6y ago
  YAML's way, way more complicated that JSON. To pick one rough measure, the spec is about 7x as long. It includes a bunch of things that could be seen as negatives, such as nine(!) different ways to write multi-line strings (https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-over-multiple-lines/21699210#21699210 https://stackoverflow.com/questions/3790454/how-do-i-break-a...). I don't have a single competitor to recommend, but JSON5, TOML, JSONC (mentioned in a sister comment), or something else along those lines might be better. I'd probably just go with whichever of those is popular in your community.
  - mpfundstein 6y ago
    i really like hashicorp hcl. more than json. (and yaml is TERRIBLE)
    - andybak 6y ago
      YAML might be terrible for the reasons given elsewhere but I really want something YAML-like (maybe TOML, maybe something else) For me, readability is king both for myself and because I sometimes want non-developers to be able to hand-edit files. Any curly brace format is a non-starter. Too much clutter, too easy to create invalid files that aren't obviously invalid at a glance. Significant white space does have the advantage of meaning exactly what it appears to mean and being intuitively understandable to most people.

Tokkemon 6y ago

Yes, definitely. Every time I work with PHP Arrays, I'm reminded both these things don't exist in JSON and it makes me sad.

dhbradshaw 6y ago

The other day I saw an auto-generated json file with comments and trailing commas and got really excited. A little digging showed that it was using JSON5. Pretty sweet! https://json5.org/ https://json5.org/

divbzero 6y ago
Cool! JSON5 looks intriguing. The core project implements a JavaScript module [1] but it looks like there are also experimental JSON5 libraries for Go [2], Python [3], Ruby [4], and Rust [5]. [1]: https://www.npmjs.com/package/json5 https://www.npmjs.com/package/json5 [2]: https://github.com/yosuke-furukawa/json5 https://github.com/yosuke-furukawa/json5 [3]: https://pypi.org/project/json5/ https://pypi.org/project/json5/ [4]: https://github.com/bartoszkopinski/json5 https://github.com/bartoszkopinski/json5 [5]: https://docs.rs/json5/ https://docs.rs/json5/ I noticed that JSON5 doesn’t include a Date type. There have been discussions about this in both the JavaScript [6] and spec [7] repos but with no resolution yet. [6]: https://github.com/json5/json5/issues/3 https://github.com/json5/json5/issues/3 [7]: https://github.com/json5/json5-spec/issues/4 https://github.com/json5/json5-spec/issues/4
- divbzero 6y ago
  What would really help JSON5 take off is if it gets bundled with browsers by default. For now it doesn’t seem all that appealing to add <script src="//unpkg.com/json5/dist/index.min.js"></script> to every HTML page as extra JavaScript instead of a native browser implementation.

smabie 6y ago

HOCON solves pretty much all the problems JSON has, including the ones you mentioned.

throw0101a 6y ago

> 2) comments Per Douglas Crockford, the creator of JSON, comments were an anti-feature: > 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. * https://web.archive.org/web/20120507093915/https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr https://web.archive.org/web/20120507093915/https://plus.goog... Discussion on the post (2012): * https://news.ycombinator.com/item?id=3912149 https://news.ycombinator.com/item?id=3912149 Remember: JSON was designed primarily as a data exchange format between computers.

MichaelMoser123 6y ago
Processing instructions can always be added as a special name value entry, that wouldn't be a good reason to get rid of name value pairs
enricozb 6y ago
This is what I figured would be the reason to remove comments, because they would hold some other non-human information. It's unfortunate that people do this. The main reason for comments for me would be for config files, which maybe shouldn't be in JSON anyways.
- throw0101a 6y ago
  > The main reason for comments for me would be for config files, which maybe shouldn't be in JSON anyways. I think this is a bit of 'over reach' in what JSON was intended to do, so it's perhaps not surprising that there may be some things 'lacking' for that purpose.

user5994461 6y ago

There you go json for humans https://hjson.github.io/ https://hjson.github.io/ This allows trailing commas and comments. This can also reads strict json of course. Libraries are available for all popular languages.