tags:

views:

3397

answers:

18

I thought XML is highly portable and can be used as a mini database. I have seen XML used everywhere. I even see large companies switching over to JSON. Even Microsoft has integrated support for JSON. What is all the hype over JSON?

+18  A: 

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>
Ron Gejman
not just smaller, but more human friendly. XML looks like a poor attempt of a human to talk like a computer.
caspin
Your XML can also reduce the XML wtih attributes instead of elements for simple types (name/value)
Matthew Whited
@Matthew: Yes, but then it looks inconsistent and ugly. And you still need open/close tags for the element. JSON (at best) halves the number of tags you need to use.
Ron Gejman
Look at Marc's example. I don't see how you version is easier to read than his. http://stackoverflow.com/questions/1743532/why-is-everyone-choosing-json-over-xml-for-jquery/1743664#1743664
Matthew Whited
difference is length doesn't seem that big to me
vtd-xml-author
@Jimmy It's more than just length-- what if this was a test configuration file for a website? I sure wouldn't want to write or edit the XML version-- too many redundant keystrokes or time spent flipping through the reference manual to relearn how the XML-aware features work. The JSON version is much easier to manage.
Sharpie
A small note, but the JSON isn't valid: You need some `"` around those strings. (The keys in your map.)
Thanatos
+11  A: 

Easy consumption by JavaScript can be one of the reasons ..

Xinus
That's the big reason I use it. Parsing xml manually is nightmarishly complex. Also, since I use Python to create the JSON in the first place, they handle data and objects in a very similar way, meaning serialization back and forth makes everything happy!
RandomInsano
+2  A: 

XML is bloated snake oil in most situations. JSON gives you most of the benefits without the bloat.

just somebody
+3  A: 

JSON has no impedance-mismatch with JavaScript programming. JSON can contain integers, strings, lists, arrays. XML is just elements and nodes that need to be parsed into integers and so on before it can be consumed.

Christian
The need to parse items does not equate to an impedence mismatch.
Rob
Then what does?
Christian
An impedence mismatch is when concepts don't map cleanly from one format to another, as with object-relational mapping. Some things are very easy to express with objects but hard with SQL while other things are easy to express using SQL, but object hierarchies have a hard time expressing them clearly. With XML and JSON, one often requires a bit more work to get to the meaning than the other, but that really depends on the parsing tools. The expressiveness is (mostly) the same.
jcdyer
A: 

Quite honestly, there isn't so much that's different between JSON and XML in the fact that they can represent all types of data. However, XML is syntactically bigger than JSON and that makes it heavier than JSON.

JasCav
didn't find your answer particularly inspiring, but it wasn't wrong so a down votes seemed unjust.
caspin
+108  A: 

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.
CMS
+1.. really.. so many different datatypes support matters a lot compared to raw xml text
Xinus
+1, especially since JSON parsing is unbelievably more efficient compared to XML parsing, even piecewise. Once the datasets you care about exceed a certain (and frighteningly small) threshold, the performance difference is noticeable.
Magsol
100 upvotes. Enjoy that gold badge.
Mike Robinson
+2  A: 

Now that there are JSON encoders and decoders for most languages, there's no reason NOT to use JSON for uses where it makes sense (and that's probably 90% of the use cases for XML).

I've even heard of JSON strings being used in large SQL databases to make schema changes easier.

Nosredna
A: 

I'm no expert by far but from the various companies I've worked for we generally use XML in small data environments or configuration values (web.config is a great example).

When you have large amounts of data, generally, you will want to report on that data. And XML is not a great source for reporting. In the grand scheme of things, it seems as though a transactional database is easier to report/search against than XML.

Does this make sense? As I said above, I'm no expert but from my experience this seems to be the case. Also, I believe Microsoft integrated JSON support due to the wave of developers moving over to client-side or scripted actions to enhance the visuals of the UI (Ajax) and Microsoft's Ajax has not been used as much as other libraries like jQuery and MooTools (Yahoo's YUI is also in that mix) due to their beautiful integration of serializable objects using JSON.

I find myself writing code now implementing the JSON serializer in my VB code. It's WAY too easy and from an upgrading/modifying standpoint, you can't beat it. It's Microsoft's way of keeping us addicted to VS I guess. I have recently converted an enterprise application to using Ajax (via jQuery) and using JSON format. It took approximately 2 weeks to do so. I actually thank Microsoft for integrating it because without it, I would have had to write quite a bit of extra code.

Keith
I think there was some confusion over the question and this answer contains a lot of speculation.
marr75
you lost me at VB
Eric P
+2  A: 

Both are great and very portable. However JSON has been gaining popularity since it serializes into less characters in most cases (which translates into a faster delivery time) and since it matches the JavaScript object syntax it can be directly translated into an in-memory object which makes Ajax a lot easier to implement.

XML is still great. JSON's just the "latest and greatest" compared to XML.

Adam
And I believe that newer revisions of JavaScript are beginning to include "safe" (eval-free) built-in JSON encoders and decoders.
Nosredna
+9  A: 
 <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.

Marc
That is still more non-whitespace chars than the JSON example. And parsing attributes can be more annoying in XML.
jmucchiello
Probably because complex types can really only be described in elements so that how most tools default. I agree that this XML is very simple to use and read.
Matthew Whited
+2  A: 

Easily parsed by JavaScript and it is lightweight (a document in JSON is smaller than a XML document that contain the same data.)

Yassir
+77  A: 

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.

jcdyer
+1 for showing what XML is really useful for. Too often people use XML even when they could get by with something much simpler.
Daniel Pryden
Yeah going to have to agree with jcd and Daniel here. Quality response on why XML is still pretty good for some things.
knowncitizen
+4  A: 

JSON is best for consumption of data in web applications from webservices for its size and ease of use, especially due to the built-in support in JavaScript. Imagine the computation overhead for parsing an xml fragment compared to the instant lookup in JSON.

A very good example is JSON-P. You can get back data from a webservice wrapped in a callback function call, like my_callback({"color": "blue", "shape":"square"}); inside a dynamically generated <script> tag so the data can be directly consumed in the function my_callback(). There is no way to get even close to this convenience using XML.

XML would be the format of choice for large documents, where you have a framework of rendering pages of data in multiple formats using XSLT. XML can also be used with application configuration files for readability among many other uses.

Joy Dutta
+26  A: 

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.

wow..well said.
Luke101
+5  A: 

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

avatar
+9  A: 

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.

Nate B
+1 for actually benchmarking it.
musicfreak
+1  A: 

JSON is effectively serialized JavaScript in that you can eval(aJsonString) directly into a JavaScript object. Inside of a browser it's a no-brainer JSON is perfectly suited for JavaScript. At the same time JavaScript is a very loosely-typed dynamic language and cannot natively take advantage of all the specific type information available contained within an Xml/Xsd document. This extra metadata (which is great for interoperability) is a hinderance in JavaScript making it more tedious and cubersome to work with.

Size vs Performance

If you're in a browser JSON is faster to serialize/deserialize as it's simpler, more compact and more importantly natively supported. I have some northwind database benchmarks available comparing the size and speed between the different serializers available. In the Base Class Library Microsoft's XML DataContract serializer is over 30% faster than their JSON one. Although this has more to do with the effort Microsoft put into their XML serializer as I was able to develop a JsonSerializer that is more than 2.6x faster than their XML one. As for payloads based on the benchmarks it looks as though XML is roughly more than 2x the size of JSON. However this can quickly blow out if your XML payload uses many different namespaces within the same document.

mythz
A: 

The only advantage of the JSON format over XML is that it is lightweight.

Andrei Rinea