[chubot]

The JSON spec [1] never had any updates, so it couldn't have diverged.

Kudos to Douglas Crockford for keeping it simple. I wish more standards committees would take a cue from him. (Looking at ECMAScript [2] and C++.)

There's been a tremendous amount of growth and value around JSON precisely because it's so simple and easy to implement.

People complain about the lack of comments and trailing commas, but I think those are really expanding on the initial use case of JSON, and the benefit isn't worth cost of change. JSON does some things super well, other things marginally well, and some not at all, and that's working as intended.

You can always make something separate to cover those use cases, and that seems to have happened with TOML and so forth.

(I recall there was an RFC that cleaned up ambiguities in Crockford's web page, but it just clarified things. No new features were added. So JSON is still as much of a subset of JavaScript as it ever was. On the other hand, JavaScript itself has grown wildly out of control.)

[1] http://json.org/

[2] https://news.ycombinator.com/item?id=18766361

[eesmith]

https://en.wikipedia.org/wiki/JSON#Data_portability_issues :

> Although Douglas Crockford originally asserted that JSON is a strict subset of JavaScript, his specification actually allows valid JSON documents that are invalid JavaScript. Specifically, JSON allows the Unicode line terminators U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR to appear unescaped in quoted strings, while ECMAScript 2018 and older does not.

[empyrical]

That bit of incompatibility will be going away when this proposal is implemented, however:

https://github.com/tc39/proposal-json-superset

[v413]

It is already implemented in the current Firefox, Chrome and Safari 12.

[chubot]

Yeah I remember that quirk, and that's why I said it's "as much of a subset as it ever was". :) Because of this issue, it was technically never a subset.

But almost all real JSON documents are subsets of JavaScript, unless they happen to have those characters.

And the salient point is that if JSON never changes, then no further divergence from JavaScript is possible.

[eesmith]

But remember that your comment wasn't actually addressing avmich's objection to the assertion "All JSON is JavaScript, but not all JavaScript is JSON".

That assertion is indeed incorrect.

avmich then wrote "I thought they diverged specifications".

That is also correct. JSON was meant to be a perfect subset of JavaScript. Instead, and by accident, it diverged from the relevant specification.

Your comment instead was mostly focused on opposition to changing the existing JSON specification, which is a different topic.

[daveevad]

> JSON allows the Unicode line terminators U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR to appear unescaped in quoted strings, while ECMAScript 2018 and older does not.

My code has parsed a lot JSON and that is new data to me. Thank you for that!

Do you know the historical reasoning for this particular deviation? Are there any infamous bugs or common use cases this departure impacts?

[avmich]

Agree.

This is another useful resource, discussed here already - http://seriot.ch/parsing_json.php - which lists relevant standards. But "the" standard is static, so divergence, is any, is with other standards (different from json.org) vs. evolving JavaScript.

[wtetzner]

> People complain about the lack of comments and trailing commas,

Yeah, I don't think JSON should include those things. I think the lack of comments makes JSON a poor format for config files, but that just means you should use another format for config files. JSON is good for machine-to-machine communication.