JSON maps well and intuitively to common datatypes: with a list and a hashmap, you can model a lot. Conversely, structs needing to be passed around in applicati

JSON maps well and intuitively to common datatypes: with a list and a hashmap, you can model a lot. Conversely, structs needing to be passed around in application code will probably be made up of stuff that maps well to JSON. XML's greater-than-blindingly-obvious impedance mismatch is a barrier to entry when an alternative, dead simple format exists. The XML ecosystem nonetheless has parts that are desirable for certain use-cases, as the reinvention of schema validation for JSON, awkward namespacing, and efforts to dabble in hypermedia linking show. The XML ecosystem didn't require these enhancements and extensions to be used, but implementations in the wild often did, which was further off-putting to newcomers. This helped JSON gain ground back when it (and the ecosystem around it) was truly minimal and simple. It also embodied the hacker, kludgey ethos and mythos, because without elaborate schemas and code generators, you'd pluck out only the fields you cared about and disregard the rest. These factors led to JSON's rise at an opportune time, giving it credence and exposure, and within a few years every hip cool API was emitting JSON and using cool methods like PUT and DELETE and throwing around terms like REST despite serving linkless structs as 'application/json'. The prevalence and staying power of CRUD HTTP APIs exchanging loosely typed JSON payloads shows that there's real benefits to semi-human-readable, self-documenting payloads that can be parsed into either rigid native datatypes, or loose collection types with ease. JSON fits into a world where stuff can be deliberately or inadvertently half-assed and still work.