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

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


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.