JSON is used because Javascript, Python and Ruby (among others) understand it without needed external libraries, and because it's fairly readable for humans.
Performance has nothing to do with it. If you want performance and have some control on your stack, you're better off with something more specialized.
JSON has been in Python's standard library since 2008.
http://docs.python.org/2/library/json.html
It's also in the Ruby standard library.
http://www.ruby-doc.org/stdlib-1.9.3/libdoc/json/rdoc/JSON.h...
JSON has been launched around 2002.
Python has incorporated one of the many existing libraries in 2008 after a lengthy discussion, the last part of which is http://mail.python.org/pipermail/python-3000/2008-March/0125...
Ruby had no support JSON for years, it has been added, in its current form, to the stdlib only in 2007.
XML has been supported by Python since 2000 (minidom + sax) and by Ruby since 2003 (REXML).
The idea that JSON is used more than XML just because programming language supports it "natively" clashes with the evidence.
I don't think neither this is the point: afaik browsers (where the most of the js is evaluated), python and ruby also have xml parsers in the "standard" lib (maybe more than one).
What really matters is that javascript, python and ruby programmers undersand JSON without crying for the "<" and ">" presents in the xmls
Consider for example trying to map:
<some-data>
<a>...</a>
<a>...</a>
<b>...</b>
<a>...</a>
</some-data>
IOW with XML you can't really do a proper mapping without an accompanying schema or other metadata, which is not true for the Json data.
If you have an a set of people, do you separate them out into a "manList" and a "womanList", and then panic about having to create a "secondManList" because some men came in after the women? If order is only important within gender, then you can happily just add the men onto the end of the original manList. If it is important across all people, then you have to have a "personList".
Just like you might have a "personList" that can contain "male people" and "female people", you can automatically map the whole sequence of "a elements" and "b elements" to an "elementList".
In the case of mixed content (text nodes and element nodes together), you would simply map them all to a "nodeList".
Also, do you really expect an automated process to do the abstraction from "female" list and "male" list to person list? That's more than just metadata that you're assuming to be in context (which was my point), but actual AI! This is very different from programming languages, where collections of things which occur within objects and structs are given names which reflect their intended meanings, like with Json.
How is this different from a Java object which contains two list members called "attributes" and "children"?
How is this different from an S-Expression containing two lists?
How is this different from a json object like {"attributes":[...], "children":[...]}? Bear in mind that there is no requirement for JSON lists to be homgeneous. {"things":[1,true,"hello",3,{"addressee":"world"},[{"greeting":"Hola"},7],false]} is a perfectly valid JSON object. You don't have to define it as {"numbers":[1,3], "strings":["hello"] ...}.
It is a pretty common behaviour, that if you want a homogeneous list of things that differ, then you make abstractions until the differences disappear, e.g in an OO situation, you go up the inheritance tree until you are at the lowest common base class. In an XML situation, that common base class is "Node".
Even in a strongly typed language that requires homogeneity in lists, the only thing you know about the list members is that they can be cast to the same type, not that the members are of that type and no other, and certainly not that they all have the same name. Consider a C++ array of CFruit objects. It may have a member that is of class CBanana, one that of class CApple, and another of class COrange. If you want to do something COrange specific with the oranges, then you have to perform dynamic_cast<COrange> on any member of that list you suspect of being an orange. The same is true in a duck-typing situation.
The reason for my male & female example is that you would normally simply have a list of people. Of course, if your model contains no base that is common to both men and women, then you can't expect the machine to work that out, but if Man and Woman both inherit from Person, or if there is no Man or Woman, just Person with a member that specifies a gender, then it's trivial.
Way too glib. There's lots of good reasons you may choose to go with that, and there's lots of reasons why you may not. DOM-based approaches pay a lot of resources for their functionality. If you don't use all of that functionality, you may lose over a SAX-based approach. If you're resource rich, hey, great, go with DOM unconditionally, but not all web apps are in that situation.
It's one advantage the XML ecosystem has over the JSON ecosystem; while JSON can be parsed in a streaming manner, you can generally count on a good XML event-based library for your environment, whereas streaming JSON parsing libraries seem more unusual. If you need it, you can count on it in XML.