5 ms·

I don't want to start some kind of "XML vs JSON" holy war, but I really do prefer JSON over XML because of how compact and readable it is. I really don't see J

by spin 13y ago

I don't want to start some kind of "XML vs JSON" holy war, but I really do prefer JSON over XML because of how compact and readable it is. I really don't see JSON as a passing trend, I see it as (almost) the most compact, succint way to express hashmaps in both human-readable and machine-readable form. (XML is big, bloated, and bureaucratic.) (It's tragic that Crockford left in all the qoutes around the keys, though. We really don't need to type those quotes.) For the past couple of years, I really have been wishing for an "XMPP, but built on JSON, not XML". Really. I want this.

deno 13y ago
> For the past couple of years, I really have been wishing for an "XMPP, but built on JSON, not XML". Really. I want this. The X in XMPP stands for extensible not XML. The reason XML fits the bill is because it has concept of namespaces, what JSON has? If you don’t have explicit namespace support how do you make your JSON variant of XMPP forward‐compatible? You don’t without making it look much, much, worse than any of the examples I’m about to show below. > (…) I really do prefer JSON over XML because of how compact and readable it is. > XML is big, bloated, and bureaucratic. My standard response to this is always “show me a JSON fragment that is shorter or prettier looking than an equivalent XML fragment.” XML can certainly be shorter than JSON and often is, and repeated tags are the best showcase for it: <user id="abc"> <phoneNo type="home">123456789</phoneNo> <phoneNo type="work">321654987</phoneNo> </user> This turns into this beautiful JSON: [ "users": [ { "id": "abc", "phoneNos": [ { "type": "home", "value": "123456789" }, { "type": "work", "value": "321654987" } ] } ] ] Oh, but what if order is important? Take this example: <policy id="123"> <drop someFilter="ghi" /> <accept someFilter="abc" anotherFilter="xyz"> <comment> This comment is quite long and spans several lines of text in pretty printed XML. But this is quite alright, because XML by default strips extra whitespace. </comment>  </accept> <drop someFilter="foo" anotherFilter="bar"> <reason statusCode="690">No reason</reason> </drop> </policy> Now you have to do it like that: [ "policies": [ { "id": "123", "rules": [ { "type": "drop", "someFilter": "ghi" }, { "type": "accept", "someFilter": "abc", "anotherFilter": "xyz", "comment": "Unfortunately the best you can do with JSON is to rely on your editor’s dynamic wrapping. And this is how you break the line: \nWhat a treat!", }, { "type": "drop", "someFilter": "foo", "anotherFilter": "bar", "reason": { "statusCode": 690, "message": "No reason"} } ] } ] ] For an example of how horrible JSON in wild can really be see Reddit’s JSON API. Because JSON has no syntax for metadata you get things like that: [ { "kind": "thing-foo", "items": [ # # list of comments or something that goes on for # two screens # ], "votes": 15 } ] See the keys are sorted for convenience. XML’s text representation is very minimal and consistent. You don’t need to quote Every Single Thing, and there are no special cases for not quoting just some type of values. The only redundant part of XML is repeating the name of the closing tag if the </element> has value. But this actually aids readability, as demonstrated above. Editing complex JSON by hand with a regular text editor is a nightmare, because of all those single '}', ']' and commas trailing for several lines when there’s any light nesting involved. Editing XML by hand on the other hand is no big deal.
- harlanji 13y ago
  Thank you for this, I have bookmarked it for future reference! I've always made the second part of your argument: that namespaces are the key feature that make XML useful, especially for the eXtensibility in XMPP. I also think that namespaces are a part of XML that few people understand, partially because many XML/XMPP implementations don't even (fully/correctly) support them. The rest of what you say is new though! The solid examples you gave for compactness/ordering were impressively concise. I'd even go further and say they generally illustrate the difficult readability that can arise in JSON with not-so-difficult requirements--I had more trouble following the JSON than the XML here, by far. I'd say the embedded comments and possibility of a schema in XML are also a bonus, to help understand the meaning if it isn't obvious. I am by no means an XML-supremicist, but I do take the unpopular view that it is a much more future-proof and natural solution for many more use-cases than it gets credit for. I'd love to see a successor that cuts out some of the warts as much as the next person, but every solution has pros/cons, and XML is a pretty good balance in a lot of cases where people refuse to look at it.
- cs02rm0 13y ago
  Not sure why you'd edit JSON by hand in general. It doesn't tend to be used for configuration files, AIUI this move is following the trend of sending JSON over the web. So surely looking at parsing JSON vs. XML in a browser is where the real comparison is?
  - deno 13y ago
    This is the most peculiar thing about the JSON mania of all. I mean your web browser programming consists of 99% DOM manipulation and suddenly everyone forgets how to do that when it comes to making Web API calls. Maybe we need jQuery for XML?
    - spin 13y ago
      My programming consists of 99% Javascript, ie, manipulating Javascript objects. The data structures (ie objects) translate flawlessly into JSON (I just gotta remember the quotes around the keys, is all...). Switching my brain from Javascript to the-data-across-the-network (and back) requires practically no effort at all, because it's the same thing. EDIT: > Maybe we need jQuery for XML? Adding more layers of complexity to deal with complexity? I am further convinced that XML is bloated and bureaucratic. I am so happy that modern browsers let met get away from jQuery. Plain, vanilla JS is better for the soul.

by spin 13y ago

deno 13y ago

> For the past couple of years, I really have been wishing for an "XMPP, but built on JSON, not XML". Really. I want this. The X in XMPP stands for extensible not XML. The reason XML fits the bill is because it has concept of namespaces, what JSON has? If you don’t have explicit namespace support how do you make your JSON variant of XMPP forward‐compatible? You don’t without making it look much, much, worse than any of the examples I’m about to show below. > (…) I really do prefer JSON over XML because of how compact and readable it is. > XML is big, bloated, and bureaucratic. My standard response to this is always “show me a JSON fragment that is shorter or prettier looking than an equivalent XML fragment.” XML can certainly be shorter than JSON and often is, and repeated tags are the best showcase for it: <user id="abc"> <phoneNo type="home">123456789</phoneNo> <phoneNo type="work">321654987</phoneNo> </user> This turns into this beautiful JSON: [ "users": [ { "id": "abc", "phoneNos": [ { "type": "home", "value": "123456789" }, { "type": "work", "value": "321654987" } ] } ] ] Oh, but what if order is important? Take this example: <policy id="123"> <drop someFilter="ghi" /> <accept someFilter="abc" anotherFilter="xyz"> <comment> This comment is quite long and spans several lines of text in pretty printed XML. But this is quite alright, because XML by default strips extra whitespace. </comment>  </accept> <drop someFilter="foo" anotherFilter="bar"> <reason statusCode="690">No reason</reason> </drop> </policy> Now you have to do it like that: [ "policies": [ { "id": "123", "rules": [ { "type": "drop", "someFilter": "ghi" }, { "type": "accept", "someFilter": "abc", "anotherFilter": "xyz", "comment": "Unfortunately the best you can do with JSON is to rely on your editor’s dynamic wrapping. And this is how you break the line: \nWhat a treat!", }, { "type": "drop", "someFilter": "foo", "anotherFilter": "bar", "reason": { "statusCode": 690, "message": "No reason"} } ] } ] ] For an example of how horrible JSON in wild can really be see Reddit’s JSON API. Because JSON has no syntax for metadata you get things like that: [ { "kind": "thing-foo", "items": [ # # list of comments or something that goes on for # two screens # ], "votes": 15 } ] See the keys are sorted for convenience. XML’s text representation is very minimal and consistent. You don’t need to quote Every Single Thing, and there are no special cases for not quoting just some type of values. The only redundant part of XML is repeating the name of the closing tag if the </element> has value. But this actually aids readability, as demonstrated above. Editing complex JSON by hand with a regular text editor is a nightmare, because of all those single '}', ']' and commas trailing for several lines when there’s any light nesting involved. Editing XML by hand on the other hand is no big deal.

harlanji 13y ago
Thank you for this, I have bookmarked it for future reference! I've always made the second part of your argument: that namespaces are the key feature that make XML useful, especially for the eXtensibility in XMPP. I also think that namespaces are a part of XML that few people understand, partially because many XML/XMPP implementations don't even (fully/correctly) support them. The rest of what you say is new though! The solid examples you gave for compactness/ordering were impressively concise. I'd even go further and say they generally illustrate the difficult readability that can arise in JSON with not-so-difficult requirements--I had more trouble following the JSON than the XML here, by far. I'd say the embedded comments and possibility of a schema in XML are also a bonus, to help understand the meaning if it isn't obvious. I am by no means an XML-supremicist, but I do take the unpopular view that it is a much more future-proof and natural solution for many more use-cases than it gets credit for. I'd love to see a successor that cuts out some of the warts as much as the next person, but every solution has pros/cons, and XML is a pretty good balance in a lot of cases where people refuse to look at it.
cs02rm0 13y ago
Not sure why you'd edit JSON by hand in general. It doesn't tend to be used for configuration files, AIUI this move is following the trend of sending JSON over the web. So surely looking at parsing JSON vs. XML in a browser is where the real comparison is?
- deno 13y ago
  This is the most peculiar thing about the JSON mania of all. I mean your web browser programming consists of 99% DOM manipulation and suddenly everyone forgets how to do that when it comes to making Web API calls. Maybe we need jQuery for XML?
  - spin 13y ago
    My programming consists of 99% Javascript, ie, manipulating Javascript objects. The data structures (ie objects) translate flawlessly into JSON (I just gotta remember the quotes around the keys, is all...). Switching my brain from Javascript to the-data-across-the-network (and back) requires practically no effort at all, because it's the same thing. EDIT: > Maybe we need jQuery for XML? Adding more layers of complexity to deal with complexity? I am further convinced that XML is bloated and bureaucratic. I am so happy that modern browsers let met get away from jQuery. Plain, vanilla JS is better for the soul.