Hacker News Reader

Comment by k_sze | Hacker News Reader

> Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas.

I think the most correct way to deal with this problem is to get IETF and ECMA to update the JSON standard first. Honestly, comma-after-final-element and comments are such important quality-of-life features that I never understood why they weren't part of the original spec.

On the other hand, it might be easier to just adopt TOML and forget about JSON.

View on HN

>I never understood why they weren't part of the original spec

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

>Trailing commas in objects were only introduced in ECMAScript 5. As JSON is based on JavaScript's syntax prior to ES5, trailing commas are not allowed in JSON.

json was largely `eval`d when it first hit the scene. It was easy to parse because you just received it and `eval`d it directly to parse. worked in every browser. security concerns over time lead to this being rightfully replaced with the JSON object and its associated encoder and decoder.

however, since early javascript didn't allow for trailing commas, neither could JSON if it wanted to be able to be `eval`d.

Interesting note: Douglas Crockford's version of JSON's origin story is great. At Yahoo Crockford wanted to return data from an API as a Javascript object because it skipped a translation step and avoided messy XML. And his bosses originally objected because there was no JSON spec. So Crockford bought a website, quickly wrote up a JSON spec and published the spec to his new official looking JSON.org site. With an official spec in place and documented on the web, there was no longer cause for his bosses to object to APIs returning JSON :)

Comments were intentionally excluded from JSON, lest they be used to instruct the parser and cause fragmentation of the ecosystem.

I know it's the official reason, but it's also a really bad one - nothing prevents current JSON parsers to add some weird syntactic rules inside plain strings (similar to "use strict" in JS), but you don't see that happen. It's always been a completely hypothetical issue.

The only real reason why comments would be problematic is that they are a pain to preserve in a consistent way when editing a file, and thus would require extra work in parsers / serializers. Still, it would be worth the cost imo.

I agree that it was stupid. I am 100% pro-comment.

In most applications reading and writing JSON are completely separate operations and roundtripping comments makes no sense.

Actual JSON-reading applications must ignore comments because they aren't allowed to care about them. On the other hand anything useful can be placed in a proper field, a comment would be a hack to pass information to human readers but not to JSON consumers (saving some time and memory). Such a technique could only be considered if people are supposed to read the JSON files and some information is useful for them but not for the reading application: a niche within a niche.

Preserving comments would actually be a complicated special purpose feature, reserved for something like structured text editors that can perform nonstandard parsing with comments included in their special object model (of the large Javascript subset/superset/variant they choose to support and roundtrip, not of JSON).

I think that json is mostly a lightweight, human-readable data exchange format for machines to communicate. It's generally not meant to be written by humans.

It's not even good for machines to communicate with, considering:

- There is no minimum/maximum number/integer value (or sizes) defined in the RFC [1] - you have no guarantee that a number you emit will be readable by all RFC-compliant parsers, so the only safe option is to emit all numbers as strings. There is also no behaviour mandated for parsers that encounter numbers/integers outside of their supported size range, so you can't rely on any fail-safe behaviour.

- There is no standardized behaviour for repeated dictionary keys (which are allowed but 'discouraged' per spec), and different implementations will treat them in different ways. This is especially painful when trying to build JSON middleware that does a parse/check/modify/emit of arbitrary data.

- Implementations in some languages (eg. Python) are non-RFC compliant by default (`python.dumps` will emit NaN/Inf/-Inf, even though the RFC forbids that), and generally all implementations are similar-but-different-enough to trip you up [2].

All three of these have bitten me in the past when trying to interface with something that spoke JSON, and as such I refuse to design new systems that use JSON as any source of truth.

[1] - https://www.rfc-editor.org/rfc/rfc8259.html

[2] - http://seriot.ch/parsing_json.php

There are already better formats if we just want machines to communicate though; e.g. protobuf, msgpack.

The whole reason JSON is text-based is to make it human-readable while also enabling data exchange, but the lack of comments works against that goal.

Not in the browser or in many stalin.

> many stalin.

Wasn't there just one Stalin, though?

One was certainly more than enough. Unfortunately, many have tried to pluralize.

Stdin. New phone, forgot to disable autocorrect.

But it's used for all kind of config files. And there I would like to comment why stuff is done the way it is.

That's not a problem with JSON, that's a problem with people choosing JSON as a configuration file format.

I remember seeing some conversation from the JSON authors around comments and specifically not allowing comments into the spec because they did not want people to use them as extension mechanisms, so the whole no comments in JSON thing was very much intentional.

Reply on news.ycombinator.com