Hacker News Reader

Comment by _greim_ | Hacker News Reader

With the exception of trailing commas, all these things would break the fact that JSON is a subset of JavaScript. Breaking that would cause a lot more problems than it solves. It's just that the minor problems you have to live with seem worse than the major problems you don't.

View on HN

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

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

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

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.

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

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

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

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.

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

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

> 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

Reply on news.ycombinator.com