Douglas built the JSON spec

1) to be language agnostic. Following ES5's syntax directions is fine for ES5 focused development, possibly not for others.

2) to be final - i.e. there is no version number. If you want to extend or build something else, I am fairly certain Douglas would prefer that you call it something else. See http://inkdroid.org/journal/2012/04/30/lessons-of-json/ at 5:30 in the video.

Don't take these points as criticisms, I too would like to be able to use single quotes and trailing commas and everything else here. I think though that in order to work with JSON as a static spec, an alternative approach could be to have your project be a layer like HAML, SASS or CoffeeScript. Each of those tools compiles or transforms to conforming input for their target specs rather than replacing them.

JSON5 is also meant to be language-agnostic. It derives its syntax from ES5 in the same way that JSON derived its syntax from ES3.

I'm aware that JSON is final — it's my hope that a new format that's easier to write (whether this or something else) picks up steam — but thanks for the feedback on the name! I consciously used a different file extension (.json5) to avoid conflicts; hopefully that's a good start.

I already use (and love) CoffeeScript, but my motivation for building this was to have tools use it natively, so that sibling files in a different format wouldn't have to be maintained alongside the needed JSON.

Please don't call it JSON. Actually I don't care much, as your project will be shunned. The first rule of JSON is that JSON doesn't change.

Why are you hand writing JSON? Pass a JavaScript object, which doesn't have these limitations, to the JSON serialerizer.

The support for evaling in the various engines doesn't matter because you should not be evaling JSON strings for security purposes.

The serialization format is strict for a reason: look at where less strict HTML parsing has gotten us.

Writing, or at least editing, JSON by hand seems unavoidable if you develop on Node, as modules' "manifests" are JSON files.

I also love to make tests data-driven where possible. JSON is the natural format for data on Node, and again, test cases are usually written by hand (before code exists to generate or validate them).

I'm not sure I understand your point about eval'ing. This parser doesn't use eval(), and it works in every modern browser.

Finally, I'm not advocating for arbitrary looseness. These additions conform directly to ES5's additions.

I believe you should do something like this:

  json.stringify({unquoted:'Some value', trailing_comma:true,})

instead of hand-writting JSON data in tests.

I have implemented a javascript eval into my text editor. When I select text, and call the command, it passes it off to a node.JS engine and replaces the selection with the return result. In this way I can write a JSON.stringify([anyvalid javascript],null, [indentation]); and instantly get perfect JSON. This is much less troublesome than trying to make a new slightly incompatible format.

I absolutely hate hand-writing JSON, but that's why I use YAML. I think you should push for a properly documented subset of YAML, or a full YAML parser in JavaScript instead. Just a Ruby programmer's 2 Eurocent :)

Thanks for the feedback! I never considered YAML precisely because there doesn't seem to be much support for it. I'll definitely look into it. =)

Horrible. There's a reason JSON is homoiconic with valid javascript. You should never have done this.

JSON is an amazing serialization format but hand-written JSON is completely wrong.

I think this fixes most of the problems of using it in hand-written situations. Just the lack of comments in JSON makes it inappropriate for configuration files and tests.

But this shouldn't be called JSON. JSON is strict and doesn't include comments because it's designed for interoperability between different systems. Just because it's been abused to be used for configuration files doesn't mean it needs fixing. One just needs to use the right tool for the job. Your project might be the right tool but then it's not JSON.

* Objects and arrays can have trailing commas.*

If I had a penny for every time a trailing comma in a json config file bit me, I would have...many pennies!

I am indifferent about single vs double quotes. The backslash newline escape seems 'messy'.

Not a fan of keys not being quoted. That stikes me as wrongish for some reason that I can't put my finger on.