Why doesn't JSON allow trailing commas? Why? How hard is that to implement? Everyone else has them, why not JSON?

Maybe just the spec guys.

It's got nothing to do with how hard it would be to implement; JSON is a data format with strict definitions and dangling commas is a sloppy notation for the convenience of developers.

Commas are delimiters, not terminators, so a comma signifies more content to come but is increasingly forgiven by languages and environments.
Any comma followed be nothing but whitespace should, by all means of consistency have the same significance, e.g. `[1,2,,3,4,]` should have either zero or two empty elements.

I can't stand this convention to include trailing comma's after the last item that has made it into linters and such, sacrificing common-sense grammar because programmers can't be bothered to type an extra comma themselves

I'm the other way around. Specs accepting trialing commas are just annoyingly facilitating laziness.

JSON isn't meant to be written. It's not a config format, it lacks a lot of things config formats need. Using it for config is the mistake. It's a data transfer format, short to save bandwidth and simple to make parsing fast, even in interpreted languages and even on low power embedded devices. It's readable for developers' convenience, but it definitely shouldn't include features to aid writing, much like HTTP isn't case and whitespace insensitive because you were never meant to write http messages by hand.

@homo-lorens
It doesn't dictate how it's used, one of its goals is to be human-readable.
Not allowing trailing commas is a JS thing historically.
@AlmondSauce
I find it annoying and causing unessesary line changes and sometimes merge conflicts in versioned JSON files

IMO, if you're using JSON right this is never an issue.

You would only run into this if you were concatenating JSON as a string... which would work... but is like the slowest most spaghetti way to create JSON.

Take the same loop, make an array or object, json encode or stringify it (or whatever for your languge), never worry about commas.

@hjk101 It doesn't state its purpose, but it's spectacularly failing at being a config format.

It doesn't have typed nodes like XML so if you want to indicate a choice with options you either fall back to strings or use a "type" field on an object.
It didn't have comments until very recently and most projects still don't use parsers that support them.
It doesn't have references so if you want to keep things in sync you either repeat yourself or generate it.
It can't be concatenated (although that hasn't been a standard feature since XML).
Because of the lack of references you can't group settings logically.

It's an abysmal format and the only reason it's popular is that you don't have to spend 2 minutes learning the syntax to use it, so you can read the configuration of all 200 dependencies to your hello world app without thinking. And I think this is a terrible reason to choose a config format.

I'm seeing projects supporting JS for configuration because JSON is lacking so many things that a programming language is closer to ideal.

I agree with OP.
Yes, directly writing json should be avoided but is still needed sometimes.
And it doesn’t look like it would introduce problems when trailing commas would be allowed. So why not allow them?

@homo-lorens I like it's condense more readable than say XML and highly interchangable. So for certain types of configuration I really like it (usually bordering on being data but manually maintained).

I thought it still didn't have comments and yes any configuration file that remotely needs clarification like that should use something like yaml, toml or UNIX style config file. XML is to much of a data format for me too for normal config.

The only reason to forbid them is because it wouldn't be compatible with all parsers that exist right now.

It's a pretty good, if standard, case of something existing because it makes sense for one thing in a specific language, and because of some positive properties it brings the use spreads to a multitude of places where it doesn't natively fit, prompting complaints because it doesn't support or conform to whatever practice or paradigm the specific use case tends to offers natively.

@hjk101 I don't like how verbose XML is, but the fact that nodes are typed, ordered and repeatable makes it a lot more suitable to represent things like rule lists and references and includes allow users to structure their options any way they like.

@Lensflare there could be plenty of reasons to not allow superfluous commas (or any character for that matter). One would again be the parsability and consistency, as my example above `[1,2,,3,4,]` should have either zero or two empty elements.

After reading @homo-lorens 's comments, I take my opinion back. Then we must strive to remove the use of JSON as a config format, specially in `package.json` and all those NPM files, and keep it only as an automated language. Let's go to GitHub and fix this once and for all!

@Flygger superfluous comma != trailing comma.
We are discussing trailing commas here, there is never a next value or closing bracket after it. The problem it solves is that you don't have to look or modify the previous line/block in *some situations*.

@Flygger sorry but I don’t get your example. What do you mean by empty value?

As others have already stated, the discussion is about trailing commas. But if I had to generalize it to your example, the resulting array would simply be [1,2,3,4]
You could interpret a missing value as a concatenation with an empty array to get that result. (An existing value would be a concatenation with an array containing that single value).

@hjk101 @Lensflare
I'm very well aware of what dangling commas are, and they are in every way superfluous as in they're not needed and contribute in no way to the outcome.
As JSON is a subset of JavaScript, dangling commas can only exist in either arrays (like my example) or objects.
In objects a member consists of a property name and value so having a comma not followed by a property name yields an "Unexpected token" error, except for the forgiving case where it's dangling as the last token in the object.
In arrays commas are delimiting values and having a comma not followed by a value yields an empty spot in the array or a "holed array", whereas a comma at the very end is treated differently with dangling commas. This makes it a sloppy and inconsistent implementation and not a suited format for representing concrete data, as illustrated by this example:
[1,2,3] => [1, 2, 3]
[1,,3,] => [1, <empty>, 3]
[1,,3,,] => [1, <empty>, 3, <empty>]

The problem dangling commas solve is lazyness.

@Flygger I still don’t know what you mean by "empty".
JS has null and undefined. But not empty. So, what would the array contain at that spots?

I just tested it, and it is 'undefined' in JS.
The holes are filled with 'undefined'.

Once again, JS is already inconsistent here, so allowing trailing commas in JSON would have even one more legit reason.

@Lensflare Undefined, but the exact value in that spot is irrelevant to the point he's making. Commas should be either forgiving in which case
,, = , and ,] = ] and ,} = }
Or strict in which case a comma not followed by an element will become an element whose value is undefined.

@Lensflare The problem here is more of a general assumption; in JavaScript an array can actually have holes as they're more like maps from indices to values and if no value is given, no index is mapped.
In ES6 the holes are _treated_ like undefined, but as you can see from the examples below, they behave very differently depending on how you treat them:

[1,,3] => [1, <empty>, 3]
[1,,3].length => 3
Object.keys([1,,2]) => ["0", "2"]
Object.values([1,,2]) => [1, 2]
Array.from([1,,3]) => [1, undefined, 3]
JSON.parse(JSON.stringify([1,,3])) => [1, null, 3]
[1,,3].join("").split("") => ["1", "3"]
[1,,3].join(",").split(",") => ["1", "", "3"]

@Flygger you still don't get it
A trailing comma is always followed by a newline :
[
{
'Something' = true,
},
]

This way it can be expanded without changing the content already there

[
{
'Something' = true,
'Else' = false,
},
{
'Something' = false,
},
]

However when going compact you can't have trailing comma:

[
{'Something' = true},
]

But that is no problem as it's clear and modification will result in line change.
So no fucking mucking around with extra commas in the data structure.

@hjk101 I do get it!
- I get that trailing means "following" as they follow the last part of relevant content.
- I get that they make it _sooo much easier_ for lazy coders to add, remove, or (comment) toggle lines.
- I get that command line heroes get a slightly bigger diff to deal with.
- I get that with common code formatting they would tend to be followed a newline.
- I get that in JSON (and most other code) whitespace is insignificant and can be collapsed or removed with no difference to the parser.
- I get that JSON is often sent with whitespace stripped.

And, unlike you it would seem, I get how JSON and other JavaScript notation actually works.

@homo-lorens as you mention richer config files using XML (cf. SOAP) are great for hierarchically structured/ interlinked configs (or encoded data).

I'm curious what format you would advocate for simpler config needs instead of JSON. As far as I'm aware, JSON, YML, TOML, INI can all be converted to one another. JSON has Jsonschema which allows some extra features and it wouldn't be hard to create combined configs using a "subconf-includekey":"file://subconf.json" convention to recursively load them into 1 another

@webketje Glad you asked, my preference would be to use whatever works. Each situation demands a different set of features, and specifying any universal standard would miss the point. Config must be problem oriented, it must represent concepts specific to the software and describe the desired behavior, so it should probably generalise as little as possible and vary depending on what you're trying to configure. If you're going to learn a new tool, config syntax is the least of your concerns anyway.

Some key points though:
Comments aren't optional. Plus you can add them to anything by discarding lines that start with a hash, so the effort will pay off by the second time a user needs them.
A format that allows redefinition can make it easier to combine configs by concatenation. Some programs allow to supply multiple configs and automatically combine them, which obviously makes this redundant.
If your project is tiny, you should use whatever the enclosing environment uses.
(1/2)

Only skip file includes if you don't have access to a file system.
You can skip references if you expect config generation, but otherwise people are probably going to miss them a lot during sleepless scavenger hunts to find the last out-of-sync port number.
<dont-repeat><yourself/></dont-repeat> unless you expect walls of text. Then do repeat yourself, a bit of repetition is nothing compared to closing brace pyramids of doom. A minor advantage of XML's repetition compared to JSON's bland pyramid is that the closing lines contain information about what's specified just above the edge of the screen.

As for existing options, I like toml and I find unix config, yaml and xml adequate (except partial yaml implementations, that shit drives me up the wall), but I care about features more than symbols.
(2/2)

@Flygger you keep calling me and other proponent's lazy and ignorant. So a Fuck you for that is in order.

- Unlike you I understand how trailing commas work including the correct implementation of the parser and minification process. Modern JS supports this in arrays, object and function parameters.
- Either the parser supports it or it gives the standard error. So stop trying to Invent issues with it
- Unlike you I've had to deal with merge conflicts. And bug hunting takes extra time because you have unnecessary line changes vying for your attention. Only to realize just a fucking comma change.
- Unlike you I've had to deal with new devs who all fall in this pitfall.
- Unlike you I understand that we are in the automation business to make life easier. If it's such common mistake, pain in the ass have a solution for it. Why the fuck not implement it.

I would say this should have been implemented before they added comments.

@hjk101 @Flygger

Without wanting to ignite a flame war, I think Flygger's examples and argumentation show that there are valid reasons (disambiguation, parsability and consistency) to not allow dangling/ trailing comma's in JSON.

I find the counter-arguments comparatively weak:
Ok the git diff will show an extra comma to an existing line, I don't see how that is a big deal or could lead to complex merge conflicts. If new JS-native devs add trailing comma's, they should learn and/or use an editor/linter which invalidates the JSON before commit. Leaving interpretation to the parser is bound to cause issues (e.g. the CI process uses a different parser than your local editor and is less forgiving)

Though I would leave a last chance to a more compelling argument that compares how property:value separators are used in other config formats (e.g. what happens when you use multiple newlines/ empty list items in a YML/TOML file?)

@webketje I agree that incompatibility with older/different parsers would be a big issue.
However, when considering changes to standards, this is always an issue. So this is not a valid argument in this case. Otherwise changes to standards would never be made.

There are some other arguments given here which are essentially pointing out problems with the current state of the standard and implementations.
But the proposal would of course change the standard, so arguing about the current state is pointless.

@hjk101 So, how are parsers and new devs handling ,, and ,] that is oh so much more logical than treating
both as undefined,
both as illegal, or
both as a superfluous comma?

@Lensflare well here's an argument in favor of keeping trailing/ dangling comma's out of the standard: semantically it has no meaning, and document standards are all about semantics. They are a client addition that make the data easier to work with for devs (not all json "viewers", eg data scientist), but still belong in the client namespace