> All JSON is JavaScript, but not all JavaScript is JSON
Really? I thought they diverged specifications long enough ago (though using those extras could be discouraged in some cases).
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/
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.