> 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>
            <!-- That’s another kind of comment, but this one is not meant
                 to be part of the data, unlike the one above. 
                 Some would say something as basic as comments is
                 an essential part of so called human‐readable format… --> 
        </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.