Can we make commas optional in JavaScript literals?

Sometimes, small improvements can go a long way to making a language more enjoyable. One thing that I seem to feel acutely for some reason is noise. Noise is those parts of the language that –with compiler changes– you could remove without changing the meaning of the program, and without making it less clear. In many cases, removing the noise would actually make the code clearer, because the reader can focus on the meaningful parts without being distracted by the noise.

While I know that the debate over ending lines with semicolons is still raging, I’ll raise a similar concern over colons in JavaScript object and array literals. I think they are noise, all of them, and that we should be able to omit them.

Here is an example of an object literal, coming from a real application:

var shell = new Shell({
features: [
'not feature 1',
'not feature 1 either'
],
availableModules: {
'path/to/module1': {
name: 'module 1',
services: {
service1: {
feature: 'feature 1',
path: 'lib/service1'
}
}
}
}
});

I think that this could be just as well written this way:

var shell = new Shell({
features: [
'not feature 1'
'not feature 1 either'
]
availableModules: {
'path/to/module1': {
name: 'module 1'
services: {
service1: {
feature: 'feature 1'
path: 'lib/service1'
}
}
}
}
});

The advantage is that you can move lines around, or delete them, without negative consequences. There is also no ambiguity being introduced that I can tell.

In fact, this problem of being able to move lines around has already been kind of addressed in EcmaScript 5, by adding more noise: you are now allowed to add trailing commas after the last property of an object, or the last item in an array. This would rewrite our example as:

var shell = new Shell({
features: [
'not feature 1',
'not feature 1 either',
],
availableModules: {
'path/to/module1': {
name: 'module 1',
services: {
service1: {
feature: 'feature 1',
path: 'lib/service1',
},
},
},
},
});

This may be more convenient, but it’s arguably even noisier, and uglier.

Of course, I’m only talking about changing this in JavaScript, not in JSON. I think it’s more realistic to attempt to change this in the language, because that would let people take advantage of it in controlled execution environments such as Node.js, without breaking anything. JSON has a number of identified issues itself, that would be arguably more urgent to fix, but this is a lot more difficult to do because it’s an interoperability standard, and you’d have to change all parsers in order to implement any change.

So what do you think? Am I splitting hair here, or is there value in escalating the idea? Did I miss something super-important that makes this a really bad idea altogether?

3 Comments

  • HOCON has capabilities like this. i've often wished i could have this flexibility with method params too, in fact i've done

    function x(
    param1,
    param2,
    _
    ){

    }

    just to make it easier to add params.
    It'd be interesting if you could opt in to features like this like you do with strict mode.

  • I'd say you missed a big point: minification. Or perhaps I'm the one missing something :)

  • @Pedro: this won't affect minification negatively (a comma and a space take the same amount of bits before compression, and the minification can put commas back in anyway). It might even help. Any change to the language syntax is going to require changes in minification code, that's expected.

Comments have been disabled for this content.