4 ms·

> JSON has become popular because a lot of bad programmers saw nothing wrong with calling eval on untrusted input (before JSON.parse was available). Disagree.

> JSON has become popular because a lot of bad programmers saw nothing wrong with calling eval on untrusted input (before JSON.parse was available). Disagree. JSON became popular because it was extremely easy to implement (both for marshaling and consuming), and because it was extremely lightweight. I think you could also make the argument that JSON was conceptually easier for programmers to wrap their minds around. You could just pretty-print it and quickly get an idea for the object's format, attributes, etc.

ams6110 10y ago
XML could be fairly lightweight also. It was all the enterprisey-standard formats that were hideous. E.g. {"name":"John","age":42} vs. <person name="John" age="42" />
- rimantas 10y ago
  Now do the nested objects in both. One line does not show much.
  - Mikhail_Edoshin 10y ago
    <person id="123" name="John" age="42" sec:checksum="..."> <family-member type="spouse" ref="456""/> <family-member type="child" ref="789" /> <fin:credit-rating score="A" last-change="2016-02-04T12:34:56Z" /> <уфмс:статус значение="42" /> </person> Here we can describe `person/@id` as element ID and `family-member/@ref` as a reference to an ID so our XML tools can link these together. Also note three more elements from different namespaces: `@sec:checksum` could be some kind of technical information about the record, `fin:credit-rating` is added by the finanical module. The `@last-change` is defined as datetime so as we read it with other XML tools we'll get it as datetime type. The next one is a tag in Russian language that describes something related to Russia; XML can use the whole Unicode in tag and attribute names. Also, XML names are globally unique by design so there's no clash between all the different pieces and the tools can easily be configured to ignore parts they don't understand or work as a glue between different areas. We can still efficiently validate the syntax the whole piece or parts of it as we see fit.
seagreen 10y ago
I agree, especially with the easy to understand part. Look how short the standard is: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf http://www.ecma-international.org/publications/files/ECMA-ST... It's small and perfect, like a 2x1 LEGO block. Here's the XML spec: https://www.w3.org/TR/REC-xml/ https://www.w3.org/TR/REC-xml/ <backs away slowly>
wtbob 10y ago
> Disagree. JSON became popular because it was extremely easy to implement (both for marshaling and consuming), and because it was extremely lightweight. A canonical S-expression parser is strictly easier to implement, given that S-expressions consist only of lists and byte sequences (no numbers or objects), and is even more lightweight. JSON's big advantage was that it was familiar to a JavaScript programmer, that's all.

ams6110 10y ago

XML could be fairly lightweight also. It was all the enterprisey-standard formats that were hideous. E.g. {"name":"John","age":42} vs. <person name="John" age="42" />

rimantas 10y ago
Now do the nested objects in both. One line does not show much.
- Mikhail_Edoshin 10y ago
  <person id="123" name="John" age="42" sec:checksum="..."> <family-member type="spouse" ref="456""/> <family-member type="child" ref="789" /> <fin:credit-rating score="A" last-change="2016-02-04T12:34:56Z" /> <уфмс:статус значение="42" /> </person> Here we can describe `person/@id` as element ID and `family-member/@ref` as a reference to an ID so our XML tools can link these together. Also note three more elements from different namespaces: `@sec:checksum` could be some kind of technical information about the record, `fin:credit-rating` is added by the finanical module. The `@last-change` is defined as datetime so as we read it with other XML tools we'll get it as datetime type. The next one is a tag in Russian language that describes something related to Russia; XML can use the whole Unicode in tag and attribute names. Also, XML names are globally unique by design so there's no clash between all the different pieces and the tools can easily be configured to ignore parts they don't understand or work as a glue between different areas. We can still efficiently validate the syntax the whole piece or parts of it as we see fit.

seagreen 10y ago

I agree, especially with the easy to understand part. Look how short the standard is: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf http://www.ecma-international.org/publications/files/ECMA-ST... It's small and perfect, like a 2x1 LEGO block. Here's the XML spec: https://www.w3.org/TR/REC-xml/ https://www.w3.org/TR/REC-xml/ <backs away slowly>

wtbob 10y ago

> Disagree. JSON became popular because it was extremely easy to implement (both for marshaling and consuming), and because it was extremely lightweight. A canonical S-expression parser is strictly easier to implement, given that S-expressions consist only of lists and byte sequences (no numbers or objects), and is even more lightweight. JSON's big advantage was that it was familiar to a JavaScript programmer, that's all.