Why is Everyone Choosing JSON Over XML for jQuery? [closed]
开发者_C百科
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this questionI 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?
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.
Easy consumption by JavaScript can be one of the reasons ..
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.
No one here has mentioned XML-s main advantage: validation rules (DTD, XSD). My conclusions, having used both:
- JSON is perfect for ajax, especially if you develop both server and client side yourself. You basically create js objects right in your server script!
- XML shines in corporate environments, when you have to set data exchange standards between big bureaucratic organizations. Often, one party develops its part months before another, so it really benefits from validating its requests against agreed XSD. Also, in big corporations, data transfer is often translated between different systems. This is also XML's strength, think XSLT. Example: code-free conversion into JSON :p
Of course, there's json-schema being developed but you won't find built-in support for it anywhere.
I'm a fanboy of both, they have just different strengths.
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.
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.
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.
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.
Easily parsed by JavaScript and it is lightweight (a document in JSON is smaller than a XML document that contain the same data.)
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.
XML is bloated snake oil in most situations. JSON gives you most of the benefits without the bloat.
One major advantage other than the ones mentioned here. For the same data, there are multiple ways to represent it as a XML file but only one way with JSON, removes ambiguity :)
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.
加载中,请稍侯......
精彩评论