
JSON5 is a proposed extension to JSON - zekers
http://json5.org/
======
tudborg
As much as i would like to see comments in json: if we start throwing around
json files that area not really json, but we call them json, (at least in
everyday talk), we will end up breaking more apps then we fix.

Maybe the question is instead; why the hell do we need comments (and loosening
of t he syntax, etc) in the first place?

Are we seriously going to keep insisting on json as a configuration format?

As Stormbrew already pointed out, we already have a format that is ideal for
configurations (and sure, data exchange, why not), and it is called yaml.

yaml have comments

yaml makes it easy to enter multiline strings

and most if all; yaml is very very easy to write!

tl;dr: Just use a format suited for your needs instead of trying to change
something that doesn't. Oh, and a couple of smiley faces thrown in there to
ensure people don't read this in the wrong tone. People do that.. Like, all
the time.. damn, now my tl;dr is too damn long! i have to add another.

tl;dr;tl;dr YAML BITCHES! (╯°□°）╯︵ ┻━┻ (but also, a puppy:
[http://i.imgur.com/kuDsS0i.jpg](http://i.imgur.com/kuDsS0i.jpg) )

~~~
derefr
If web browsers had native YAML parsing, we probably wouldn't need JSON5. Web
browsers aren't going to get native YAML parsing.

~~~
stormbrew
They probably aren't going to get native json5 parsing either (except in the
sense that you can do something stupid like eval it). That said, I don't think
there's any particular need for yaml in the browser. Browser code is usually
dealing with machine-generated data, where even normal json is just fine.

~~~
derefr
Rich client-side apps need configuration files too.

~~~
yeukhon
If this was merely a configuration (say for node.js) which sits on the server,
then you probably just import a npm to read yaml (I don't write node.js so I
don't know if using .yaml is feasible as node.js config file or not). So the
use case is limited.

I used to work on a project which users could edit a configuration file
through a web editor and we chose YAML because writing JSON by hand is painful
(I hate the comma error!). But we processed this YAML file for the user on the
server side, so having a native YAML parser in browser and Javascript wouldn't
really help me at all.

~~~
derefr
No, I'm talking about configuration files that get interpreted by code that is
executing within the browser.

For example, a configuration-data file format for specifying a "brush" in a
JS-client paint program. That'd obviously be a schema on top of JSON, right?
Well, now you've got all of JSON's inherent limitations.

~~~
j03w
Then you don't need JSON, all you need is the plain old JS object.

~~~
derefr
You're thinking of the live representation of the "model" of a brush in the
program. I'm talking about the "definition" of a brush, from which the program
_loads_ that model. Another example would be, say, a "level" in an HTML5 game.
These things ship alongside the game as blobs of data. Those blobs need a
format that the browser can parse. Currently, JSON is that format, and it's
inadequate for that.

------
shirro
This brings barely anything useful to JSON and adds processing overhead.
Almost all json is produced and consumed but software not people. Adding
trailing commas or single quotes or optional quotes is a waste IMO and adds
needless complexity for very little gain. Now if they were introducing some
useful new types that would be a different matter.

~~~
typicalbender
It's interesting, the first thing I thought of when looking at this was CSON
([https://github.com/bevry/cson](https://github.com/bevry/cson)) which
essentially just provides some syntactic sugar on top of JSON like
CoffeeScript to JavaScript. I haven't look at this enough to really see the
difference between JSON5 and CSON but at the surface it looks like its just
CSON rebranded as JSON5. I agree with you that in general most json is machine
generated and in most cases should never be manually created by people. It's a
language for machines to talk to machines not machines to people. Granted it's
sort of against JSONs philosophy but I also would love to see some more types
added to JSON rather than syntactic sugar. There will always be libraries like
CSON or CoffeeScript to add sugar, its better to make the base more useful and
extendable.

~~~
mistercow
It looks to me like a major difference between this and CSON is that this is
safe and CSON is not.

Literally the only difference between coffeescript.eval and cson.parseSync is
that the latter runs in a sandbox. You can't screw up so badly as to cause
global side effects, and you can't require modules, but that's where the
safety ends.

For example

    
    
        cson.parseSync("Math.sqrt")(4)
    

will return 2, and

    
    
        cson.parseSync("1 while true")
    

will cause an infinite loop.

That's very powerful for config files; I'd much rather have my config say "y:
Math.sqrt 2" than "y: 1.4142135623730951". But it means that you absolutely
must not parse CSON that comes from an untrusted source.

Now obviously JSON5 provides very little over JSON as a data-exchange format.
In fact, the only practical advantage I see is that you can use Infinity as a
value.

I can see two use cases for this:

1\. You have a web service for developers, and you want human-editable config
files that can be parsed safely on the server side. CSON won't work there, and
JSON5 would be nicer to work with than JSON. It's a good thing that JSON5 is a
strict superset of JSON, because this is one hell of rare scenario.

2\. You want your exchange format to be more human readable for debugging and
testing. This use case isn't realistic, however, so long as JSON5.stringify is
aliased to JSON.stringify.

~~~
matthewrudy
The unsafe eval of objects in CSON seems to be an implementation quirk rathet
than a feature. They're working on a static parser.

Check out their WIP
[https://github.com/bevry/cson/issues/33](https://github.com/bevry/cson/issues/33)

~~~
mistercow
That's good. It would be nice if they'd document the spec before doing this.
Right now it's pretty unclear what is and isn't valid CSON, since any
CoffeeScript code will run.

------
raymondh
Disruption for basically zero benefit.

The proposed modifications are utterly trivial and don't really make anyone's
life better.

~~~
stevenleeg
As someone who writes a large amount of node/js, this would definitely make my
life easier for when I have to write out a package.json, some other sort of
json config, or test data (which happens a lot). All of the proposed changes
would take away annoyances that I experience being a human that has to
occasionally write JSON by hand.

As a side note, negativity for the sake of being negative does not help the
conversation at all. Please take that kind of attitude somewhere else.

~~~
serge2k
Expressing the opinion that these are not useful ideas isn't "negative for the
sake of being negative".

These are poor modifications. Don't modify JSON to be a better configuration
format, just use a better format.

~~~
mgkimsal
"just use a better format."

Rather hard to do when the rest of the world you need to interact wouldn't
necessarily move with you.

------
stevoski
We should add namespaces to JSON. And schemas. And schema validation. And
stylesheet transformations. Yes, that would all be good...

Extensible types would be the next thing to add.

Now that'd be a good extension.

And we could call it Extensible JSON language. A good abbreviation would be
XJL.

And eventually we'd have a standards-body defined way of querying JSON
documents. We could call it JQuery.

(</sarcasm> just in case...)

~~~
thousande
we should also have JSON comments

~~~
alanh
I have no idea why you said this in reply to a sarcastic post, because

\- we SHOULD have JSON comments. Have you never edited a JSON-based config
file?

\- No one says that HTML or XML shouldn't have had comments

\- JSON5 already suggests adding comments, so your proposed extension to a
sarcastic proposed extension to a serious proposed extension is idempotent

------
drawkbox
JSON really shouldn't change at all that is why it is so great, basic types
and very simple and clean. We should build a fortified defense around JSON and
keeping it the same.

Of course there is no problem making a new standard, mongo did that with BSON.
It is different and should be called different, nothing wrong with
abstractions.

The reason we all love JSON is that it has stayed the same. Develop a
coffescript like JSON precompiler with comments and trailing commas and all
sorts of things like no quoted keys if needed but call it something different.
I think the last thing anyone wants to do it shake the JSON standard or have
to have multiple parsers try for all the new JSON
formats/schemas/namespaces/etc like an XML SOAP nightmare.

EDIT: Ok so it does have compiling to regular JSON but just not a fan of the
name.

 _This file is written in JSON5 syntax, naturally, but npm needs a regular
JSON file, so compile via `npm run build`. Be sure to keep both in sync!_

~~~
stormbrew
> Develop a coffescript like JSON precompiler with comments and trailing
> commas and all sorts of things like no quoted keys if needed but call it
> something different.

Someone did, it's called yaml.

~~~
theg2
And I still don't understand why you'd pick yaml over anything else out there.

~~~
stormbrew
I pick it for config files humans have to write and read because writing and
reading json as a human is tedious and error prone.

~~~
vertex-four
As someone who has to write yaml... writing yaml is significantly more error-
prone than JSON. It has _far_ more edge cases than JSON does.

~~~
stormbrew
I agree it has a lot of corner cases, but they are mostly in service of
allowing for an uncluttered document. The fact that you can always write a
subset of the document in json is helpful when things get hairy.

But this is a thing that often gets ignored when talking about what humans are
good at reading and writing. We aren't computers (or at least, we aren't as
linear of computers). It's obvious enough in the languages that we speak and
write every day with each other that we derive from and plant a lot of meaning
in the margins of our expression. We tend to understand things quite clearly
when noise has been elided out. A lot of JSON becomes pure noise: "{{[[{[{{[".

Really, though, what I'm most in favour of is that now that we've agreed on a
basic data model that is less insane than its obvious predecessors (ASN.1 and
XML) it would be nice if applications with configuration opened themselves to
allowing the user to decide the specific format for their own benefit. If it's
TOML or JSON or JSON5 or JSON+comments (Sublime Text) or YAML or whatever, so
long as it results in the same structure who cares?

~~~
TheZenPsycho
> A lot of JSON becomes pure noise: "{{[[{[{{[".

I'd rather that be visible brackets than invisible whitespace.

~~~
stormbrew
Why?

Assuming 'invisible whitespace' in this context is actually a meaningful
thing. I find it hard to _miss_ indentation, if anything, to the point that
given a conflict between whitespace and a sea of brackets/braces my first
instinct is probably to trust the whitespace. I don't think I'm alone in that.

~~~
TheZenPsycho
so do you use tabs or spaces. or tabs AND spaces. Is that 2 spaces or 4? or
did I accidentally put 5 in somewhere? is a trailing space going to cause
problems or not? Text editors certainly don't help keep this stuff straight. I
just don't think white space should be part of the syntax. It makes editing
HARDER. not easier. And it's not even visible, unless I turn on a special
feature in my text editor.

I just don't know what exactly you YAML guys are smoking that you think it's
easy or more humanistic.

~~~
stormbrew
...

So, in YAML you can only use leading spaces. Leading tabs are an error. This
confusion of yours is not at all present in the actual thing you're talking
about. And if you mix them in json god help you if your editor settings don't
match someone else's because you might be looking at something nearly
incomprehensible that won't error or warn at all.

I mean, have you ever actually looked at a code file of any sort with mixed
tabs and spaces when the person who wrote the file had a different tab stop
than you? This is a readability problem _no matter what_. Forcing you to have
sane indentation is a feature of whitespace-sensitivity, not a bug.

What exactly do you think trailing whitespace does?

If I'm smoking something, at least I've used the things I'm talking about
instead of spreading weird FUD.

~~~
jasonlotito
> at least I've used the things I'm talking about instead of spreading weird
> FUD.

> A lot of JSON becomes pure noise: "{{[[{[{{[".

Pro-tip: if you are going to call someone out for not knowing a format and
spreading FUD, don't post things where you do the same exact thing. It pretty
much invalidates the criticisms you've been making as it says "I don't know
what I'm talking about, here is proof."

~~~
stormbrew
That'd be cute if what I said there didn't come from experience, even if I did
exaggerate the specifics.

Yes, the specific sequence of tokens is not valid because a list obviously
can't be a key. The idea is still the same. I'll fix it so it is a valid
sequence of tokens that's just as confusing: "}}}]}]}}"

~~~
TheZenPsycho
honestly that's a code smell in any data serialisation notation. if you really
did have a data structure like that it would manifest in yaml as an
indentation 32 space characters. If you adhere to the 78 column rule, you've
squeezed most of your data to the right of almost half your screen.

Anyways, invisible syntax errors still suck. At least with json you can
(eventually) figure out your braces are unbalanced. Or use a syntax
highlighter to spot the problem. No syntax to highlight if you have a problem
with yaml.

------
mmastrac
I love this concept; my only concern is that by adding comments, it becomes
difficult to round-trip a JSON document. XML has the concept of comment nodes
that can survive a round-trip, but there's no easy way to do this in JSON.
Perhaps you could limit where comments could go (ie: tagging object properties
or array items only) and add a "__comments__" property to an object and/or
list that contains the matching comments for the items in the object and/or
array.

Also, please add ISO-8601 dates (repeating my comment below)!

{ timestamp: new Date("2007-04-05T14:30Z") }

~~~
hcarvalhoalves
What's the benefit of cluttering JSON with a constructor like new Date(...)
when you can just standardize on ISO-8601 strings? JSON is not supposed to be
eval'ed anymore.

~~~
mmastrac
JSON _is_ JS. If I manually create a JSON document, it should also be valid in
the context of code. And strings are not dates -- they are strings. That's why
we have boolean and number literals.

~~~
bennyg
So many other languages use JSON as a data format that keeping a weird
constructor call in there would do more harm than good. Especially since you
can keep the formatting code in your codebase and invoke that when you need to
use that property.

------
nardi
I love how this proposal "fixes" a bunch of non-issues, while making it much
more difficult to write a JSON parser, and then doesn't address the only real
problem with JSON:

That it doesn't have a date/time type.

~~~
rwmj
More fundamentally: JSON doesn't have a well-defined _integer_ type. A JSON
parser that accepted just 0 and 1 as the only integers would be conforming.

And this causes real bugs in real programs:

[https://lists.gnu.org/archive/html/qemu-
devel/2011-05/thread...](https://lists.gnu.org/archive/html/qemu-
devel/2011-05/threads.html#02162)

~~~
haberman
What would you prefer JSON had done?

Defined numbers as int64? Or arbitrary precision bignums? Then JavaScript
would not be able to support JSON without an external bignum library, which
many/most applications do not actually need, and JSON would be less convenient
to use.

Or would you prefer they had specifically defined IEEE double precision as the
numeric representation? Then JSON numbers would be useless for qemu's offsets
and other applications that need numbers not representable as IEEE double
precision.

Leaving it unspecified means that implementations support what they can. If
you end up needing actual int64s in JavaScript, you can drop in a BigNum
library and get them. It's true that not all numbers can be represented by all
implementations, but that was true already.

~~~
rwmj
Provided a rich range of integer types, with specifications in the standard.
Leaving it unspecified is really the worst choice if you trying to
interoperate with real applications and libraries. Supporting "what they can"
is great for crappy implementations, and terrible if you're trying to consume
this stuff and get work done.

~~~
haberman
A "rich range" of anything is contrary to the spirit of JSON. JSON became
popular in part because it was a much simpler contrast to technologies like
XML that provided a "rich range" of everything.

Leaving it unspecified means that JSON as a format is capable of arbitrary
precision, without requiring that implementations carry around bignum
libraries if their particular application doesn't need them.

------
quux
The only thing JSON needs is a standard date type. All these JSON5 additions
are a waste and in some cases harmful.

Example: Comments were taken out of JSON because some parsers started using
them to store processing instructions.

------
Silhouette
This is a terrible idea.

JSON has been successful because it found a sweet spot between three factors:

1\. It is useful. There is enough flexibility to represent most structured
data easily.

2\. It is portable. There are libraries to read and write JSON data in every
major programming language.

3\. It is simple and unambiguous.

Things like allowing keys to be unquoted if they're valid identifiers _in
JavaScript_ and _as JavaScript happens to be defined by the latest standard_
save two characters, at the expense of breaking portability and future-
proofing, making the specification more complex, and introducing ambiguity.
This is not a worthwhile trade-off.

------
ChikkaChiChi
This just seems to fix problems for the lazy or those that lack architectural
rigidity in their development patterns.

JSON is a data encapsulation format that doesn't care about the data contained
within. That is up for your programs to consume and decide.

If you think JSON needs "more" like comments, parsing, multi-line, etc. then
perhaps you need to revisit your architecture.

If you disagree I am sure there are plenty of frameworks out there that will
babysit your data and document things for you. But upsetting the core apple
cart here would be a huge mistake.

~~~
derefr
The support for numeric Infinity is basically the one unabashedly-semantic
modification; it doesn't go far enough, though, since it should be possible to
serialize _any_ float, valid or invalid, in a data-exchange format. I'd think
proper support would involve a Rational representation--encoding Infinity as,
say, 1/0.

------
meritt
Where do I go to vote against this? Just write a script that just converts
your invalid JSON into real JSON.

------
hyp0
These are all good ideas, but will NOT be adopted.

Trailing commas are especially appealing: it simplifies outputting JSON from
"(A , ) * A" to "(A , ) * ". In fact, in this respect, XML is easier to output
than JSON.

But it will not be adopted. Crockford already removed comments from the JSON
spec once. Guy knows what's up: it's a standard, keep it simple. If you want
the kitchen sink, use XML. JSON5 will achieve about as much adoption as yaml:
some. Having json in the name and syntax won't bring massive adoption.

~~~
captainmuon
This is not _meant_ to be adopted, as in, replacing JSON everywhere.

It doesn't make sense for REST APIs. It doesn't make sense for communication
between programs. In fact, its basically impossible to use this implementation
for that, because (the last time I checked) JSON5 just used the JSON reference
serializer. If you create JSON programmatically, it will always be valid
vanilla JSON!

The use case is hand-written JSON. Either for configuration files (like
Sublime Text). Or if you have hand-written data that you would otherwise put
in a object in a .js file. You might want to separate your data from your
code, but you can't just dump the javascript object literal into a json file,
because it's not valid JSON. And maybe you want to leave comments in there, or
trailing commas in lists.

If you send JSON over the wire, its trivial to sanitize it:

    
    
        JSON5.stringify(JSON5.parse(sloppy_json))
    

This will also remove comments of course, if you are concerned about them
eating bandwidth.

------
jaytaylor
It allows trailing commas, and claims IE6 compatibility. I don't understand
how both can be true.

    
    
      In Internet Explorer 6 and 7, there is an easy to introduce
      javascript bug relating to commas. If, when defining an 
      array or an object, you leave a trailing comma after the 
      last item in your collection, IE will fail to parse your 
      javascript file:
    
        var x = [1,2,3,]; //ERROR
        var y = {'a': 1, 'b': 2, 'c': 3,}; //ERROR

~~~
russellsprouts
They wrote a custom parser that works in all browsers -- it doesn't use eval.
JSON5 is a subset of ES5, not a subset of JavaScript that runs in all
browsers. Notice that it also allows reserved words as keys -- an ES5 feature
that doesn't work even in IE8.

------
Encosia
A successor, revision, or update to JSON must address Dates to have any hope
of displacing JSON 1.0.

~~~
captainmuon
This is not meant to displace plain JSON!

JSON5.stringify(obj) produces plain compliant JSON. Using JSON5,
programattically produced JSON will always be JSON 1.0. This is for
configuration files, and static (hand-edited) data.

And what is wrong with just using ISO dates in strings? I mean whats the
difference between, say:

    
    
        "date": /2010-03-23T23:57Z/,
        "date": Date(2010-03-23T23:57Z),
    

or whatever the syntax would be and

    
    
        "date": "2010-03-23T23:57Z"
    

? The irony is that JSON5 without dates is more compatible with JSON, than any
JSON implementation with dates. (JSON5.stringify(JSON5.parse(...)) always
produces pure JSON without loosing information. I don't know how you would
convert a date literal into regular json other than turning it into a string,
on the other hand.)

------
rjzzleep
JSON5 == kinda cson?

although i think coffeescript object notation was an unfortunate name choice.
people averse to coffee will immediately associate bad thoughts with it.

[https://github.com/bevry/cson](https://github.com/bevry/cson)

------
jonpaul
I honestly thought TOML
([https://github.com/mojombo/toml](https://github.com/mojombo/toml) \- created
by founder of Github) was a good configuration format. But unfortunately, I'm
not sure that Tom has been a good steward of it and most of the interest in
the early dies died off because Github issues would go unanswered or
unresolved for months.

~~~
stock_toaster
Same here. I have been keeping an eye on libucl[1] lately. The nginx-like
config style seems very nice. I ran across it when looking at FreeBSD's pkg-ng
(it uses it). I haven't seen any libs for it in any other languages yet
though, so maybe it will end up being just another 'also ran'.

[1]: [https://github.com/vstakhov/libucl](https://github.com/vstakhov/libucl)

------
AndyKelley
Most of this is already implemented in my C library called "liblaxjson" [1]

I did it because I had a use case where the JSON file is for user input, not
for computer-to-computer communication. So I wanted it to not be so annoying
to edit and more importantly, to allow comments.

[1]:
[https://github.com/andrewrk/liblaxjson](https://github.com/andrewrk/liblaxjson)

------
Thiz
This is what json should have been from day one.

How many fields in all json streams ever transmitted aren't alphanum
compliant? My bet is 99% of them are simple names, so forcing it to be
surrounded by quotes for that 1% is just a waste of chars and shift keys, even
if they're mostly automated.

I spend a lot of time designing, testing and validating apis for which I have
to read tons of json, and believe me, without quotes my life would be so much
easier.

Comments are also important for testing. Trailing commas would save plenty of
extra code to remove them from lists.

These improvements would be mostly welcome.

~~~
TheZenPsycho
the reason the quotes were added to keys is not alphanumeric compliance. It's
avoiding javascript reserved words like "do" and "class".

------
kgabis
This adds too little and too late (not that much should be added to JSON). And
parsing some of these features would be a headache and a possible source of
bugs (I maintain a JSON parser in C[0]). Keeping it simple is much more
important than adding new features.

[0] [https://github.com/kgabis/parson](https://github.com/kgabis/parson)

------
berdario
Almost all of the issues solved by JSON5, are also solved by EDN:

[https://github.com/edn-format/edn](https://github.com/edn-format/edn)

I'd like to see a little bit more love for edn... and if you're gonna pick
something incompatible with plain old JSON, why not edn?

~~~
captainmuon
I can only speak for myself, but I don't want something incompatible with
JSON, or completely different.

I want a format that looks like Javascript or Python code, and that is a
strict superset of JSON (e.g. can parse all valid JSON). I want to pluck my
object or list literal from my Python or JS code, put it into a config file,
and have it work, no matter wheter I have final commas in lists or not. I want
to be able to insert comments. And I want to be able to describe it as "JSON,
but you can use comments", so people will be able to understand it immediately
and edit the files. This is similar to what Sublime Text uses for its config
files, for example. EDN, or more prominently YAML are just not well-known
enough (and the latter is hellishly complicated).

Also, a nicety of JSON5 is that it serializes into plain JSON, so
interopability is always ensured.

------
NathanOsullivan
How about defining a format for dates? That would be more helpful than most
the proposed changes here.

~~~
randallsquared
What's wrong with ISO-8601?

~~~
mmastrac
I'd like to see explicit date types using ISO-8601 format, ie:

timestamp: new Date("2007-04-05T14:30Z")

~~~
tudborg
Your appliation needs to know that "timestamp" is a timestamp anyway. Why
would you want to add that to your data as well?

~~~
azinman2
To make parsing easier? By the same logic why differentiate between numbers,
strings, and booleans?

~~~
tudborg
Because those are javascript primitive types, which json is built around in
the first place. Date is not a javascript primitive, and is therefore not
included.

If we need to follow that logic (to include useful non-primitives) we would
end up with a clusterfuck of a spec that noone would want to implement.

------
Mouq
I agree that JSON5 misses much of the spirit of JSON's simplicity, but I build
a Perl 6 JSON5 parser for fun anyway, if anyone is interested:
[https://github.com/Mouq/json5](https://github.com/Mouq/json5)

The actual grammar is here:
[https://github.com/Mouq/json5/blob/master/lib/JSON5/Tiny/Gra...](https://github.com/Mouq/json5/blob/master/lib/JSON5/Tiny/Grammar.pm6)
(it would be nice if Github's syntax highlighting for Perl 6 regexes was more
sophisticated than "turn it green," but I'm glad it syntax highlights in the
first place)

------
kenperkins
Good Ol Hacker News, regurgitating something from 2 years ago:

[https://news.ycombinator.com/item?id=4031699](https://news.ycombinator.com/item?id=4031699)

That said, Aseem is very sharp. Nice to see this come up for discussion again.

------
pfraze
Nice work, aseemk. I put together a quick jsperf [1]. JSON5 code was copy-
pasted into setup, since it isn't on a CDN (that I saw).

1 [http://jsperf.com/json-vs-json5](http://jsperf.com/json-vs-json5)

------
jrochkind1
For what really happens when you add lots of convenience features to something
like json -- it's not XML, it's YAML.

And it turns out all those extra convenience features in YAML are a mess -- if
you haven't discovered that yet, it's becuase you haven't been bitten by a
weird edge case related to the complex interplay of features yet.

Of course, this proposal is just a few convenience features, it's not nearly
to YAML level. That probably also means it doesn't add enough benefit to any
developers pain points to justify anyone using it instead of the more
universally recognized plain old json.

------
davvid
I'm eagerly awaiting the C, C++, and Python implementations. Has anyone
started on these?

Extending rapidjson, jsoncpp, yajl, and simplejson seems like a natural place
to start.

~~~
captainmuon
I have a python implementation, but haven't found the time to share it yet.

Funnily, I independently "invented" this before I found JSON5. I called it
"yottson", because that's how JSON would be pronounced in German and what I
sometimes call it in my head. Its a fitting name, because it is my
ideosyncratic "almost JSON".

Formats like this are mostly meant to be used for configuration files. For
example the sublime-text configuration files are JSON + comments. I don't know
what all the hate is for, it's clear that you wouldn't send this over a wire
to a client expecting pure JSON. In fact, the serializers in JSON5 and in
Yottson only ever create standard-compliant JSON. Its a case of "be liberal in
what you accept, strict in what you send".

One thing I'd still like to implement though is lossless parsing. The parser
would keep track of all the comments and whitespace, so that when you change a
value programmattically in the config file, it only modifies the value and
preserves all the indentation and comments. Right now, as I mentioned, writing
the file programmattically always results in pure compliant JSON, but kills
all comments.

------
ape4
I would love to not have to quote identifiers!

------
angelortega
Commas and colons are unnecessary clutter in JSON, that's what they should
change, not adding more complexity in exchange for nothing (dangling commas at
the end? please). Quotes inside keys and values should also be optional unless
they contain spaces.

JSON should be simplified (if any), not made it more complicated.

------
al2o3cr
"JSON isn't the friendliest to write and maintain by hand."

And this is a problem why, since it SHOULDN'T BE WRITTEN BY HAND?

This suggestion adds additional complexity to every parser of the "new"
format, in exchange for... nothing, apart from a few less syntax errors for
sloppy hand-editors. WTF.

~~~
diydsp
I have a silly question, only having used JSON a precious few times, but if
people want comments in JSON, couldn't that be done just by a named field
within an object that follows the existing specification, iow an optional
property holding a string?

~~~
MichaelGG
By doing that, you've now added more data to the object. It'd be like doing
<tag comment='bar' /> in XML - the actual data has changed.

So you'd end up defining some well-known comment name. But then you can't
serialize arbitrary data structures, because they might conflict. So that gets
complicated.

After everything, the JSON spec could have allowed comments to stay in.
Instead, the author went off on some nonsense reasoning about incompatibility.

------
MilnerRoute
How hard would it be to just parse JSON5 into JSON? (Strip out the comments,
add quotes around keys, eliminate trailing commas from objects and arrays...)

Once that's in place, then JSON5 would instantly become much more viable...

------
northernman
I really hope this idea dies quickly.

One of the best things about json is its simplicity and rigid syntax.

If we open up this can of worms, we will incur thousands of man-years of
future wasted time tracking down incompatibility issues.

------
leeoniya
a bit OT, but you guys might find this useful.

JSONH is json for homogenous collections, read: csv files.

[https://github.com/WebReflection/JSONH](https://github.com/WebReflection/JSONH)

------
haxander
Want comments and all kinds of other goodies in your config? Why not make a
config.js that offers full configuration language flexibility?

~~~
captainmuon
That is what this is.

------
aaronsnoswell
The one best thing about this - comments.

------
DrBazza
Obligatory xkcd - [https://xkcd.com/927/](https://xkcd.com/927/)

------
005-18
Hexadecimal numbers and object keys without quotes would be useful to me. The
rest of it ... meh.

------
adrianpike
On the plus side, since it's all optional, we can all start claiming
compliance immediately.

------
thatthatis
"[objects, arrays, ] can have trailing commas."

That's all I needed to hear, I'm on board.

------
willvarfar
Comments are not in json for a well understood reason:
[https://plus.google.com/app/basic/stream/z12ztpczbxrdglfgl04...](https://plus.google.com/app/basic/stream/z12ztpczbxrdglfgl04cipiaorjydfxg5tc0k)

I want trailing commas.

But the delta confuses me - what is it and how is it used and can it be
negative?

~~~
just2n
Crockford does opinionated wrong. It's fine to be opinionated, but it's not
fine to give absurd (often stupid) justifications for actions and beliefs that
are wrong:

"I removed pointers from C because I saw people were using them to manipulate
implementation defined details of their environment, a practice which would
have destroyed interoperability. I know that the lack of pointers makes some
people sad, but it shouldn't."

Another of my favorites is the justification for part of why jslint is
unusable in any real environment because Crockford thinks anonymous functions
are unprofessional and only used by people who don't know what they're doing:

[https://groups.yahoo.com/neo/groups/jslint_com/conversations...](https://groups.yahoo.com/neo/groups/jslint_com/conversations/topics/1553)

~~~
macspoofing
>It's fine to be opinionated, but it's not fine to give absurd (often stupid)
justifications for actions and beliefs that are wrong

That's asking Crockford to not be Crockford.

------
rbobby
Dates... where are the dates!

------
Raticide
OMFG comments are allowed! Was it so hard to allow those in the first spec?

~~~
jfischer
I think comments are really a bad idea. If you want comments, either make them
explicit properties in your data structures or use something else like YAML or
XML. JSON is the most practical language out there for inter-machine and
inter-program data representation.

JSON has two unique properties among data representation languages that make
it useful for certain types of tasks: 1) it is very simple to write conformant
parsers and serializers, and 2) the parsed representation contains all the
original semantic information in the original document (excluding maybe
whitespace). If you have a separate syntax for comments, then parsers must
either drop the comments (making transformation tools less powerful) or parser
must provide a more complex representation (e.g. like the DOM) and drop the
simple map/list/scalar data model.

Please don't make JSON the next XML! Source: I spent about 5 years suffering
with XML in the Enterprise Application Integration world.

------
kirkbackus
This is pretty unnecessary. If you need all these things, just use XML.

------
codehero
I couldn't tell, does the Numbers support include NaN?

------
finishingmove
Stopped reading at "can have trailing commas"...

~~~
lucian1900
They are really useful. The only two good options are allowing trailing commas
or considering all commas to be whitespace.

~~~
finishingmove
They are ugly.

~~~
mmastrac
They also make JSON generation by machines much easier, and don't complicate
the parser. [1]

[1] Source: I've written a JSON parser from scratch and think it would be
valuable

~~~
stormbrew
More importantly, they make it possible to have not-ugly documents (commas
where they belong, after the clause they extend) work well with version
control and merging.

    
    
        -   "blah"
        +   "blah",
        +   "blorp"
    

is far uglier than any trailing comma ever has been.

~~~
finishingmove
Is that a problem that should be solved on a data format level or a version
control level?

~~~
stormbrew
Do you have a proposal to achieve solving it at the version control level that
doesn't require either a complete paradigm shift in programming and data
formatting langauges to everything being trivially an AST or embedding
knowledge of every format ever invented to your version control?

Because it seems a lot easier to just design newer languages to be friendlier
to version control than either of those. JSON has little excuse here, even
when it was 'invented' it was a bad idea to simply run it through eval and
pray it had nothing malicious or damaging in it, so compatibility with IE6's
stupid parser wasn't really all that special. Never mind that it didn't take
off as a really popular format until well after that was a concern.

~~~
TheZenPsycho
if text editors can syntax highlight why can't version control systems syntax
version?

------
hydrogen18
I'll propose this: websites should be readable.

------
fisherprice
JSON is perfect as it is, leave it like it is.

------
jokoon
what about a open binary format ? I don't mean bson.

------
bsimpson
Yes, please.

