Hacker News Reader

Comment by enricozb | Hacker News Reader

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)

View on HN

> 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.goog...

Discussion on the post (2012):

* https://news.ycombinator.com/item?id=3912149

Remember: JSON was designed primarily as a data exchange format between computers.

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

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.

> 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.

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.

Re: "[Comments are a] bad for a data interchange format though, because people inevitably start putting important data in them"

Any feature or tool can be abused and misused. Comments are useful for configuration files, period.

JSONC is a thing and has both of those features. VS Code used it all over the place.

OP did said that those features are good for a config format, and that's precisely how vscode uses it.

For data interchange formats comments do presents major problem.

So Yaml?

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...).

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.

i really like hashicorp hcl. more than json.

(and yaml is TERRIBLE)

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.

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/

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

[2]: https://github.com/yosuke-furukawa/json5

[3]: https://pypi.org/project/json5/

[4]: https://github.com/bartoszkopinski/json5

[5]: 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

[7]: https://github.com/json5/json5-spec/issues/4

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.

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.

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.

You should try XML. You may like it.

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"

JAXB is at the same time awesome, and completely terrifying.

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.

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.

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.

What do you mean by schema? JSON supports schema with libraries included in most popular languages nowadays. 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.

8) date types

So basically EDN.

Right

> 4) optional schemas

Perhaps CDDL:

* https://tools.ietf.org/html/rfc8610

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

An integer datatype would also be very useful. 53 bits isn't always enough.

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.

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.

There you go json for humans 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.

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

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.

Reply on news.ycombinator.com