Trailing comma's, really?? Its is so fucking ugly and inconsistent. Either ALWAYS have traling commas, or never have it. And since the meaning of a comma is separate two items, a trailing comma makes no semantical sense, the only reason you want it because A) youre lazy B) you dont know howto properly serialize to json (youre doing string manipulation probably C) you never heard about the .join function D) you dont know how to read a diff E) you dont do syntax checks before you deploy your code

Trailing commas reduce cognitive load. I don't need to consider whether an element I'm adding is the last item in a set; there isn't an edge case. Also, I can more quickly scan a DIFF and see the change in a file.

A) Wat.

B) Somebody's gotta write those serialization libraries, and they probably do a fair amount of string manipulation to do so.

C) You can't .join data streams without buffering, which defeats the purpose.

D) Adding commas on a preceding line every time you add a new item to a list can pollute diffs.

E) Trailing commas are syntactically correct in ECMAScript 6, and supported by a fair few other languages.

It's fine to disagree, but you need to calm down.

I was crossing my fingers for that too. I create JSON files a lot. It's annoying when I'm _reordering_ elements separated by newlines. It's annoying when I'm generating JSON files and I have to code in a special case to skip the comma. It breaks the consistency that I just desire as a programmer.

Why do you manually code json?

I built a game that uses JSON for metadata and config files.

You could have used yaml.

... The irony of yaml being human and version control friendly but including massive amounts of serialization mechanism vs. json being for data exchange and having extremely rudimentary serialization features aside.

because that is what json is for

no, that's not what json for. JSON is for exchange data between machines. We already have data interchange formats for humans, we call those 'languages'.

Yes, yes. And we could also have everything as binary. Now, UNIX people decided long ago to use plain text to communicate between processes, mostly because it's infinitely easier to read - and makes it possible to edit by hand if you need to. Have to interface with a REST API which consumes JSON and you want to do some testing? Open your text editor anywhere curl is installed, and you're done. That's pretty damn convenient.

We can't have everything as binary, because us humans can't even agree on which bit is most significant out of a list of 64/32/16/8 bits.

Also becoming commonplace as a config file format.

Yeah. On the other hand, I find YAML much better for this kind of thing. JSON is readable and writable by hand, but it's not terribly nice.

No doubt they both have their benefits, however in an environment particularly suited for working with JSON, like node.js, the additional overhead of a YAML (or other) parser may not be desirable.

Why not? After all, since JSON is not a proper Javascript subset, you still need to parse it somehow. And as JSON is a proper subset of YAML, you should get by with a YAML parser.

I think JSON being a subset of yaml is one of THE biggest mistakes YAML made, second only to making YAML a serialization format.

If so, use Protobuf, BSON and jump in the wagon for SPDY.

Why JSON at all if you don't care about reading it?

I'm not against Protobuf, BSON, SPDY and the likes, my argument is just that JSON is used over binary formats only because it's readable.

It must be nice to live in a world in which you never have to read JSON. Or, for that matter, any other format which is used to exchange data between machines - binary included. Worse, sometimes even XML.

I should like to visit that world one day.

json.org:

> JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.

The primary purpose of JSON is to exchange data between machines. You may have missed that part.

Sure, it's easy to read and write by humans, because it's simple, but that's not what it is for (which is what I was disagreeing with). Humans communicate better using a natural language, not JSON, as evidenced by the fact that both our comments are in English, not JSON.

And 'easy' is relative anyway. Some of my users have to write JSON (they're not developers). It would be much easier for them if the UI had built the JSON for them, while they click on buttons.

I frequently use it for settings.

What does trailing comma support get you?

It simplifies generating JSON, since you don't need a special case for the last item, and it simplifies editing it, since you don't need to do something special when adding a new item at the end. I can't see any benefit to not having it, honestly.

> It simplifies generating JSON, since you don't need a special case for the last item

In which language can't you do array.join(",")? You can even do that in Java with one of the myriad of string libraries. I haven't hand-coded joins since (at least) six or seven years.

Join doesn't help to stream to JSON from a database cursor. Unless you buffer the response first which is pretty horrid.

Fair point.

For large code bases, you don't break git blame by adding in new arguments. And it's one less thing to think about when editing your code: always add a comma, never worry about errors because you need to add a comma to the line above.

This is why you prepend the comma before every succeeding item in a list or map.

This is what I do, but it basically just has the effect of making the first item special instead of the last. That's usually better in practice, though.

You've slightly improved the problem by moving it away from the last item on the list, but you've now screwed up the first item. You can no longer insert a first-item using the same format, and instead of a trailing comma bug you can get a starting comma bug.

This seems to only move the problem to the first item instead of the last one, not solve it.

The ability to be lazy.

If I could down-vote this lazy, drive-by, language bashing I would. Back up 'so messed up' or keep comments like this to yourself, they don't help the discussion.

It is a terrible language, though. That's common knowledge.

It is, however, wrong to say it's terrible because of laziness.

I really don't think it's fair to say it's a terrible language. It does have some terrible, horrible parts. But it also has some wonderful, awe-inspiring, mind-blowing parts. It's just not a MOR language - you have extreme lows and awesome highs.

I would say that Javascript is not too bad a language because it has those nice parts. But overall, it's still a language that feels weird given all the bad parts.

I still don't get around how `this` can be so broken.

"wonderful, awe-inspiring, mind-blowing parts"

Honest question: Such as?

closures, prototypical inheritance, the syntax for object/array literals. and I know it's not strictly part of the language, and it's deeply unfashionable to say so, but I'm quite a fan of the DOM, too.

Closures and literals are pretty basic things for many languages and very well-known.

Prototypical inheritance may have gotten much more exposure via JS, but I'm not overly impressed with it, and I hardly think it makes up for the rest of the language.

fair enough; JS introduced me to closures, so I'm a bit biased.

LOL! Obviously I struck a nerve. I thought it was obvious to everyone the problems of Javascript as a language. For laziness, how about weak typing and defining a class using a function. Plenty more examples, but you can do your own research if you are curious. BTW I like and use Javascript, but it is still a crap language.

The ability to use a for-each loop rather than an iterator or iterated for loop.

Anyone compiling a list of talking points for why s-expressions aren't so crazy after all, should add this to the list. (Just append it to the list, no comma required; i.e. pun sorta intended.)

I'm actually very confused by it - I thought the specification for ECMAScript 3 already specified trailing comma support for JSON. Will need to look it up...

ECMAScript 3 did not allow trailing commas in object literals, its section 11.1.5 is:

    ObjectLiteral :
        { }
        { PropertyNameAndValueList }

whereas ES5's is:

    ObjectLiteral :
        { }
        { PropertyNameAndValueList }
        { PropertyNameAndValueList , }

And while JSON is strongly inspired by javascript's object notation, it is not actually javascript: their strings are subtly incompatible (JSON allows U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR in quoted strings, javascript does not).