Fixing JSON

What value is there in having JSON be a subset of JavaScript? In fact, it would be a good idea to make it not be a subset of JS, because that would prevent people from evaling it.

Most major browsers now support non-eval JSON parsing that it's a moot point - but it still requires it to be valid JSON, also be be usable in javascript out of the box.

JSON has the same thing going for it as the h.264 video codec - it may not be _the_ best/most open/etc. format around, but it is one of the few that is supported out the box by all major browsers and Just Works™ (with it's shortcomings).

It wouldn't be JSON then. Give this new thing a new name and move on.

Sure, but there's a difference between "we shouldn't break an existing format" and "it has to be a subset of JavaScript".

To be honest, I agree that there's really no point in changing JSON. I do think there's value in using something other than JSON.

It's also (almost) a subset of Python, and possibly other languages. The benefit is that it is trivial to remember, because you already know the syntax. And you can not just eval it (which you if course shouldn't do if you didn't write the JSON yourself), but more important you can just copy it into your code. Or start with a object literal in code, and when it grows, or you want to use real-world data, switch to an external data source.

There are a couple of projects which extend JSON. I believe an ideal JSON superset would be compatible with ECMAScript 6 object literals, and have comments and trailing commas.

Using JSON in javascript to transport data from some backend language to the browser in a simple and easily-parseable format is probably the most common use case for it - and no one has to worry about JSON support on the frontend as long as it's a valid subset of javascript, because it "just works" as long as javascript works.

Breaking that would only lead developers to write code to unbreak it.

To be pedant, JSON is NOT a subset of Javascript [1], using U+2028 or U+2029 inside a JSON string is perfectly valid, but is not in Javascript.

[1] http://timelessrepo.com/json-isnt-a-javascript-subset

Don't forget also that large integers are perfectly valid JSON (which imposes no semantics on numbers except that they are representable in decimal), but do not survive translation to JavaScript, which has only IEEE floats.

JSON is pretty close to being a subset of Lua, as well.

> It's also (almost) a subset of Python

Yes, one of my main uses of JSON in my personal projects (and at one of my previous companies) is to serialize a Python dict to disk or network (and to read a Python dict from disk or network, of course). If I keep the members to int/float/str/dict/list, it works beautifully, and if I need to serialize anything more complex, I can always use jsonpickle.

> What value is there in having JSON be a subset of JavaScript?

* Virtually zero learning curve if you already know JS.

* It can be pasted into and out of a working program.

* Constrains the format from becoming bloated.

the loose specifications of json types is my biggest gripe as the maintainer of a json library. if json mandated that all strings be representable as utf8 byte sequences (after resolving escapes) and that all numbers be representable as ieee 754 doubles it would be much easier to provide sane and consistent defaults for encoding and decoding. as it is all implementations have to make explicit choices as to how to handle things like escaped strings that represent invalid utf8 byte sequences (like `"\uD800"`) or numbers unrepresentable with a double (like `1e400`). there isn't even any sort of consensus on how to decode a number representable as an integer. some implementations produce integers, others floats

Isn't the simple solution to decode e.g. a number as a special type, say JSON_number, which can fully represent what's on the wire? Then the user can access the number via one of a number of conversion functions depending on the native data type he/she wants (e.g. JSON_number_to_float). Is there really a huge benefit to eagerly performing this conversion?

that's a simple solution yes, but also a verbose one. the primary appeal of json as a data exchange format is that it maps to ubiquitous types like objects/hashmaps, arrays, strings and numbers. if you need to hint the decoder or manually perform conversions it loses a lot of appeal as a user

> Virtually zero learning curve if you already know JS.

What if you know other languages but not js?

> * It can be pasted into and out of a working program.

Again only true for js

Well = vs : is a bit different. And requiring quotes around keys.