Why does JSON have commas?(simonsafar.com)
simonsafar.com
Why does JSON have commas?
https://simonsafar.com/2025/json_with_no_commas/
62 comments
Jokingly, why does Javascript have the semi-colon “;”
I really with the semicolon weren't optional. Its "I'll take my best guess" parsing is maddening.
One that keeps killing me is:
One that keeps killing me is:
return
(complicated-multi-line-computation)
return (
(complicated multi line computation)
)There are a few minor, uncommon edge cases, probably only encountered by minimisers, where automatic semicolon insertion may cause unintentional behaviour, so semicolons are required. One of the specs; https://262.ecma-international.org/7.0/#sec-rules-of-automat... (link from an earlier comment of like) spells it out in detail.
While these edge cases are fairly rare in everyday JS codebases, Typescript adds some, e.g. inline type casts for function calls:
const foo = someFn()
(foo as Bar).doSomething()Relying on the inherent JavaScript compatibility hack has caused as many problems as it has solved. Plus, the additional of trailing commas made a mess of things once more, forcing developers to let go of the direct compatibility with many versions of JavaScript engines and redirecting them to specialised JSON APIs instead.
The easy solution would be to go the JavaScript route and make commas optional, like JavaScript does with semicolons. You could even introduce vague and easily forgotten rules about commas being inserted between oneliner dictionaries.
I think the question "why" is easily answered, but "why should it still" is more difficult.
The easy solution would be to go the JavaScript route and make commas optional, like JavaScript does with semicolons. You could even introduce vague and easily forgotten rules about commas being inserted between oneliner dictionaries.
I think the question "why" is easily answered, but "why should it still" is more difficult.
The author knows that. Fourth paragraph.
If the author knows that, why even bother with writing a whole "what should have been" article? It could not have been any oher way.
> > ... feels like an evil plan to have more syntax errors, with no obvious benefit
> ... before you criticise something and claim it is useless.
These 2 statements feel quite far apart.
> ... before you criticise something and claim it is useless.
These 2 statements feel quite far apart.
If it is "just JavaScript", why the lack of comments ?
Comments were intentionally excluded to prevent the use of parsing directives.
(Sadly, Crockford's post about this reasoning was on Google Plus and is no longer online.)
(Sadly, Crockford's post about this reasoning was on Google Plus and is no longer online.)
{comment : "your comments here!"}
{copyright comment : "JSON doesn't require/enforce specific comments is a good thing" }
{comments : "JSON parser is not an 'comment' editor! }
Don't know whtat the google plus article covered, but Crockfor's comments : https://www.linkedin.com/posts/douglas-crockford-724600109_j...
{copyright comment : "JSON doesn't require/enforce specific comments is a good thing" }
{comments : "JSON parser is not an 'comment' editor! }
Don't know whtat the google plus article covered, but Crockfor's comments : https://www.linkedin.com/posts/douglas-crockford-724600109_j...
I think the spirit is forbidding creative developers from using the comments to include active content. I know people who if struggling with datetime encoding, would add a "// DATEFMT: YYYY-D-M" comment and be on their merry way, making it incompatible with all other JSON parsers.
What might be nice is to add a prefix to key name that indicates 'this is a 'internal document reference', skip this unless quests to parser to not ignore. Would allow for describing encoding method(s) used. date format comments being very helpful. Technically, can do by just dropping by key name.
Why comment on a format vs. adding an associated "key""format" with format information. aka date : 25.02.04 date-fmt : YY.DD.MM
Why comment on a format vs. adding an associated "key""format" with format information. aka date : 25.02.04 date-fmt : YY.DD.MM
Yet another example/demo of "Use the source!"
There is nothing in the JSON spec that prohibits pre/post non-json parsing search / replace 'end of line' marker with one or more commas.
JSON spec just tells one what the JSON parser expects, not what the end user needs/wants. (GPT-JSON not withstanding)
There is nothing in the JSON spec that prohibits pre/post non-json parsing search / replace 'end of line' marker with one or more commas.
JSON spec just tells one what the JSON parser expects, not what the end user needs/wants. (GPT-JSON not withstanding)
We can throw away colons too. Dictionaries will be sequences of “key””value””key””value”
Just because we can throw away redundancy doesn’t mean we should
Just because we can throw away redundancy doesn’t mean we should
This is how Clojure does it.
https://clojure.org/guides/learn/hashed_colls#_creating_a_li...
https://clojure.org/guides/learn/hashed_colls#_creating_a_li...
And iOS programming makes you fill dictionaries with alternating k,v,k,v,nil
*The Swift language (not only iOS programming at all)
*it is one way of initializing a dictionary. Literal way has a closer to JSON form.
EDIT: Oh you seem to be talking about ObjC it seems! I did not see the nil. Literal way is still more akin to JSON though.
*it is one way of initializing a dictionary. Literal way has a closer to JSON form.
EDIT: Oh you seem to be talking about ObjC it seems! I did not see the nil. Literal way is still more akin to JSON though.
The problem is not commas, but the fact the specification does not tell you MUST, in a conforming parser, handle extra commas at the end. While commas are not very useful in this case, they have some value because:
1. They help humans parse the JSON object: we are helped by structure. 2. They add redundancy of information and allow for simpler spotting of syntax errors.
What JSON really needs is to extend its syntax to allow strings that are prefixed length, without the need of a binary protocol. "foo": 6="foobar". Otherwise JSON forces you to parse byte by byte, which is extremely inefficient for large amounts of data.
1. They help humans parse the JSON object: we are helped by structure. 2. They add redundancy of information and allow for simpler spotting of syntax errors.
What JSON really needs is to extend its syntax to allow strings that are prefixed length, without the need of a binary protocol. "foo": 6="foobar". Otherwise JSON forces you to parse byte by byte, which is extremely inefficient for large amounts of data.
Kinda answers its doe question though
To be fair, dictionary one-liners might be a tiny bit less easy to read:
{"key1": "value1" "key2": "value2"}
Not just a bit less easy, a lot less easy
To be fair, dictionary one-liners might be a tiny bit less easy to read:
{"key1": "value1" "key2": "value2"}
Not just a bit less easy, a lot less easy
He also accounts for that immediately by saying they should therefore be optional.
a hugely uneasy to read indeed. I feel wasted time to read the article. So horrible.
In EDN[1], which is to Clojure as JSON is to JS, commas are whitespace (as it is in Clojure itself).
1: https://github.com/edn-format/edn
1: https://github.com/edn-format/edn
Readability matters and humans like that. Otherwise XML would have won.
https://guidetogrammar.org/grammar/twain.htm
https://guidetogrammar.org/grammar/twain.htm
I don't find commas at the end of line adding any more readability than avoiding them, except for the oneliner counter case.
JavaScript has optional separators (semicolons) with some rules to avoid ambiguity. Not everyone like it (I use semicolons in JS unnecessarily because I can't be bothered to learn the three edge cases they're not optional). I think there's something to be said for "commas are optional except in oneliners".
Languages like Go describe structs without commas. It took me some getting used to, but it's really not more or less readable in my opinion.
JavaScript has optional separators (semicolons) with some rules to avoid ambiguity. Not everyone like it (I use semicolons in JS unnecessarily because I can't be bothered to learn the three edge cases they're not optional). I think there's something to be said for "commas are optional except in oneliners".
Languages like Go describe structs without commas. It took me some getting used to, but it's really not more or less readable in my opinion.
If readability was the only criteria perhaps YAML deserves to win. For some data XML is more readable, its complexity is the bigger problem.
People went all in with things like XSLT and namespaces, Java became the "language that transforms XML into stack traces" for no good reason and complex XML monstrosities were considered normal so when something simple came along it was a much needed breath of fresh air (we were even prepared to overlook its lack of comments). If it wasn't JSON it would have been something else, I'm sure.
People went all in with things like XSLT and namespaces, Java became the "language that transforms XML into stack traces" for no good reason and complex XML monstrosities were considered normal so when something simple came along it was a much needed breath of fresh air (we were even prepared to overlook its lack of comments). If it wasn't JSON it would have been something else, I'm sure.
YAML seems easier to read, but for me it's much harder to actually read properly since so many things are ambiguous. JSON is very explicit - you always know the data type you're looking at. YAML has a bunch of special cases that you have to remember, and these frequently lead to bugs.
The best example are boolean values. With JSON, you have `true` or `false`. With YAML you have all of these: y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF
The best example are boolean values. With JSON, you have `true` or `false`. With YAML you have all of these: y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF
We are trained from a very young age, as a rule, to see the comma. The semicolon, not so much. Semicolons are unusual: they are not part of story telling; they are from a forgotten grammar which is hardly used.
Pooh had wandered into the Hundred Acre Wood, and was standing in front of what had once been Owl's House. It didn't look at all like a house now; it looked like a tree which had been blown down; and as soon as a house looks like that, it is time you tried to find another one.
What do you mean, not part of story telling? There are 64 semicolons in The House at Pooh Corner; and by the way, nearly all of them are followed by conjunctions.
What do you mean, not part of story telling? There are 64 semicolons in The House at Pooh Corner; and by the way, nearly all of them are followed by conjunctions.
I get the argument, but I can't imagine a double-blind study of children or adults of any age that would find they see a semicolon versus a comma at a different rate. If anything, the reverse argument works; the semicolon is more obvious because it's so unusual.
The main reason behind JSON widespread usage is human readability.
What exactly is the problem?
By that logic one could argue the whole JSON format is bad because of all the key name redundancy.
By that logic one could argue the whole JSON format is bad because of all the key name redundancy.
{ "interests": ["编程” "reading" "travel"] }
is written
{ :interests<编程 reading travel>, }
in raku literals, quite a lot less wiggling of the pinky than the authors “maximal” proposal
yeah raku : perl without the line noise
is written
{ :interests<编程 reading travel>, }
in raku literals, quite a lot less wiggling of the pinky than the authors “maximal” proposal
yeah raku : perl without the line noise
I kinda disagree with the conclusion. Punctuation is important to humans, it makes it more parsable/readable. I just accept that in a multi-line context they are not so useful, because the newline acts like a kind of punctuation. So I could make them optional and provide some recommendations: use them in a single line, and don't use them when a newline follows.
I wrote my own language mainly to get rid of commas and colons, and I added comments while I was at it.
https://github.com/paulmooreparks/Xfer/tree/master/ParksComp...
https://github.com/paulmooreparks/Xfer/tree/master/ParksComp...
Neat. Did you have any thoughts on json5 or hjson?
These JSON versus YAML versus whatever discussions seem to mainly be arguments from people hand-coding it in grey ASCII with no tools. IMO the ASCII itself just needs to be machine-readable, because humans have visualization tools to parse it and give a pretty view. I'm not Rain Man.
When it comes to serialization or sending data over the wire (non http), I prefer relaxed json (no quotes on keys e.g. {a:1,b:"hi"} ).
It keeps the message readable and it can be re-assembled on the server. That is if MessagePack or CBOR are not an option.
It keeps the message readable and it can be re-assembled on the server. That is if MessagePack or CBOR are not an option.
Makes sense. A PEG would probably be the same length as the original json format.
If it's about readability, you could have a rule "either comma or line break".
anyone actually use comma-first syntax? It lets you easily move lines around, too:
{"foo": "bar"
,"baz": "hehe"
,"yes": "aligned"
,"better": "this way"}more easy how?
Not the top one!
This has the same number of lines that can’t be moved freely as comma at the end.
But visually easier to check
Also you can put the last brace on its own line
> But visually easier to check
I’ll agree with that, since they’re all vertically aligned.
> Also you can put the last brace on its own line
You can always put the first and last brace on their own line in most languages whether the commas are at the front or end.
I’ll agree with that, since they’re all vertically aligned.
> Also you can put the last brace on its own line
You can always put the first and last brace on their own line in most languages whether the commas are at the front or end.
But in the comma-first case that lets the last line be movable, that was my point basically.
Haskell culture tends to do this kind of stuff for records, FWIW. Of course, in this case, it might even make sense to render this in a way such as the following:
Admittedly, it would look nicer if we could have trailing commas, though. Oh well, we have YAML for extra readable record syntax, even with how horrible YAML can get in reality.
{
"foo": "bar"
, "baz": "hehe"
, "yes": "aligned"
, "better": "this way"
}
Admittedly, it would look nicer if we could have trailing commas, though. Oh well, we have YAML for extra readable record syntax, even with how horrible YAML can get in reality.
My opinion: just have commas be optional, like semicolons.
Allow linebreaks to insert implied commas
Allow linebreaks to insert implied commas
Criticizing JSON for needless commas with a post full of needless ellipses.
At this, the me was enlightened
Why? What does he actually gain? The small convenience of skipping a comma in the one specific case where a human is reading pretty-printed JSON?
It's an adamant No from me.
It's an adamant No from me.
In configuration languages such as HCL, having to account for the fact that there will not be a comma for the last element becomes unnecessarily difficult.
It helps to learn your history before you criticise something and claim it is useless.
JSON is the way it is mainly because it is just JavaScript and that meant that every browser in the world already supported it before JSON was even invented. It is THE reason why it is as popular as it is.