Why is Everyone Choosing JSON Over XML for jQuery? [closed]

Question

Basically because JSON is recognized natively by JavaScript, it's really lightweight, minimalistic and highly portable because it relies only on two fundamental structures:

• A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
• An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

XML doesn't really begin to shine until you start mixing together different namespaced schemas. Then you see JSON start to fall down, but if you just need a serialization format for your data, JSON is smaller, lighterweight, more human readable, and generally faster than XML.

I find that a big benefit of JSON over XML is that I don't have to decide how to format the data. As some have shown, there are numerous ways to do even simple data structures in XML -- as elements, as attribute values, etc. Then you have to document it, write up XML Schema or Relax NG or some other crap... It's a mess.

XML may have its merits, but for basic data interchange, JSON is much more compact and direct. As a Python developer, there is no impedance mismatch between the simple data types in JSON and in Python. So if I was writing a server-side handler for an AJAX query that was asking about snow conditions for a particular Ski resort, I would build up a dictionary like follows:

conditions = {
    'new_snow_24': 5.0,
    'new_snow_48': 8.5,
    'base_depth': 88.0,
    'comments': 'Deep and steep!',
    'chains_required': True,
}
return simplejson.dumps(conditions)   # Encode and dump `conditions` as a JSON string

When translated through JSON (using a library like 'simplejson' for Python), the resulting JSON structure looks nearly identical (except in JSON, booleans are lower-cased).

Decoding that structure only requires a JSON parser, whether it's for Javascript or Objective-C for a native iPhone app or C# or a Python client. The floats would get interpreted as floats, the strings as strings, and booleans as booleans. Using the 'simplejson' library in Python, a simplejson.loads(some_json_string) statement would give me back a full data structure like I just made in the above example.

If I wrote XML, I'd have to decide whether to do elements or attributes. Both of the following are valid:

<conditions>
    <new-snow-24>5</new-snow-24>
    <new-snow-48>8.5</new-snow-48>
    <chains-required>yes</chains-required>
    <comments>deep and steep!</comments>
</conditions>

<conditions newSnow24="5" newSnow48="8.5" chainsRequired="yes">
   <comments>deep and steep!</comments>
</conditions>

So not only do I have to think about the data that I may want to send to the client, I have to think about how to format it. XML, while simpler than plain SGML by being more strict with its rules, still provides too many ways to think about that data. Then I would have to go about generating it. I could not just take a Python dictionary (or other simple data structure) and say "go make thyself into my XML". I could not receive an XML document and immediately say "go make thyself into objects and data structures" without writing a custom parser, or without requiring the additional overhead of XML Schema/Relax NG and other such pains.

The short of it is that it's just much easier and much more direct to encode and decode data to JSON, especially for quick interchanges. This may apply more to people coming from a dynamic language background, as the basic data types (lists, dictionaries, etc) built in to JavaScript / JSON directly map to the same or similar data types in Python, Perl, Ruby, etc.

The performance of JSON isn't much different from XML for most use cases, JSON isn't well suited and readable for deeply nest structures... you will run into ]]]}], which makes debugging difficult

It's lightweight compared to XML. If you need to scale, reduce your bandwidth requirements!

Compare JSON

 [
      {
           color: "red",
           value: "#f00"
      },
      {
           color: "green",
           value: "#0f0"
      },
      {
           color: "blue",
           value: "#00f"
      },
      {
           color: "cyan",
           value: "#0ff"
      },
      {
           color: "magenta",
           value: "#f0f"
      },
      {
           color: "yellow",
           value: "#ff0"
      },
      {
           color: "black",
           value: "#000"
      }
 ]

to XML:

 <colors>
      <color >
           <name>red</name>
           <value>#f00</value>
      </color>
      <color >
           <name>green</name>
           <value>#0f0</value>
      </color>
      <color >
           <name>blue</name>
           <value>#00f</value>
      </color>
      <color >
           <name>cyan</name>
           <value>#0ff</value>
      </color>
      <color >
           <name>magenta</name>
           <value>#f0f</value>
      </color>
      <color >
           <name>yellow</name>
           <value>#ff0</value>
      </color>
      <color >
           <name>black</name>
           <value>#000</value>
      </color>
 </colors>

Just an anecdote from my own personal experience:

I wrote a small Javascript directory, first with the data in XML, and then adapted it to use JSON so I could run them side-by-side and compare speeds with Firebug. The JSON ended up being approximately 3 times faster (350-400 ms vs. 1200-1300 ms to display all data). Also, as others have noted, the JSON is much easier on the eyes and the file size was a good 25% smaller due to the leaner markup.

 <colors>
      <color name='red'     value='#f00'/>
      <color name='green'   value='#0f0'/>
      <color name='blue'    value='#00f'/>
      <color name='cyan'    value='#0ff'/>
      <color name='magenta' value='#f0f'/>
      <color name='yellow'  value='#ff0'/>
      <color name='black'   value='#000'/>
 </colors>

With attributes, XML is nice. But for some reason, home-made XML is generally 100% made of elements, and ugly.