We did so because the JSON RFC permitted implementations to accept extensions, and trailing commas are nice for humans to be able to use. The down side is that accepting extra syntax like this makes interoperability harder: implementations which don’t implement the same extension, for reasons every bit as valid as those of implementations allowing the extension, are disadvantaged. ES5 weighed these concerns and chose to precisely specify permissible JSON syntax, putting everyone on the same page: trailing commas are not permitted. Therefore, the examples above should throw a SyntaxError per ES5.

SpiderMonkey has now been changed to conform to ES5 on this point: trailing commas are syntax errors. If you still need to accept trailing commas, you should use a custom implementation that accepts them — but best would be for you to adjust the processes that produce JSON strings including trailing commas to not include them. (If you are an extension or are in privileged code, for the moment you can use nsIJSON.legacyDecode to continue to accept trailing commas. However, note that we have added it only to accommodate legacy code in the process of being updated to no longer generate faulty input, and it will be removed sometime in the future.)

I think the culprit began when Douglas defined the versionless JSON spec. It prevented him from defining a second version of the spec (because you can’t indicate JSON version being sent) and as a result proper JSON always quotes property keys and has no trailing comma’s.

I guess the TC39 wants to adhere to the formal spec as much as possible. And since I doubt JSON will ever get a v1.1 or v2 spec… even though Ecmascript obviously could do without these limitations. Especially since the elision was explicitly added to the ES5 spec.

I agree that the Ecma spec could easily be changed to allow this. Since the only reason ES would require proper JSON are the JSON methods, the spec could easily be changed to support these.

I think what trailing commas helps most is the automated generation of a json string. With it, you need neither to know in advance if there will be a next element nor to special case the first element.

It helps also editing by allowing to move around elements without having to edit the number of commas at the end. With it, you can put each element on a line, and then reshuffle the lines as needed without having to care if a line will become the first or become the last.

When editing C and Java code, I keep wishing trailing commas were allowed.

I don’t know ES5’s reasoning. Precise specification does accord with ECMAScript’s historical tradition of having semantics precise enough to prohibit implementations from being observably different. (Think of order of evaluation of arguments to functions, which many other languages leave unspecified, for example.) I suspect it’s mostly that no-trailing-comma was what the RFC stated, which made its semantics easiest to adopt. The point about interoperability concerns if ECMAScript went beyond the narrowest specification in the RFC remains, however.

Postel was wrong. Accept-liberally inexorably digresses into accept-junk for game theoretic reasons: defection is less painful than cooperation. Rigorous specification a la ECMAScript’s traditional mode of operation or HTML 5’s parsing algorithm is really the only way to do it.

This change will not lead to parsers written in JavaScript again. First, no other browser accepted trailing commas, so you couldn’t have written much code that relied on this. You could easily run into precisely the interoperability problems I alluded to in the post. Second, you can change your JSON-generating code to produce conformant JSON, as I expect those few who relied on trailing commas will do, to escape the performance cost. I suggest using a more lenient implementation only as a temporary workaround. (Although, to be sure, it’s completely up to you if you want to use it for a longer time.)

[…] JSON parsing in Firefox 5 to be fast and fully conformant with ES5. For awhile we’ve made improvements to JSON by piecemeal change. This worked for small bug fixes, and it probably would have worked to […]