From my understanding, JSON won over not because it's superior, but it's much easier to build and consume.
To some degree, YAML seems to be liked because of the very same feature of Python: Scoping via indentation. However, I'm not sure about that.
XML is akin to space shuttle. Complicated but, well thought out. Well designed for its mission, robust, but somewhat clunky. However, it's a much more accessible member of "software engineering for the enterprise" era.
These features are not fit for today's "fast" software engineering. Who'll parse that XML, yet alone verify it? Who'll write the callbacks? Or is a DOM parser better? Today people "don't have time for that (TM)".
On the more realistic side, XML is really useful and robust. Yes, it's not as fast to implement, but it's forgettable. Add a DTD verification step, then parse away. After ironing the kinks out, your parser can outlive Voyager probes, maybe even humanity itself. But it's overkill for most "move fast, break things" projects of today.
I for one, will use XML for the foreseeable future for my projects. Won't whine for consuming JSON and writing hard to understand YAML files, but if I'm going to exchange big, important data and store it on disk, it'll be XML.
Here's the thing: for that article standard use case, if I want to do anything more interesting with the document body than just hand it off to a web browser, I need to parse it anyway. I've not saved any work at all. For the specific case of semi-structured documents, JSON just isn't the right tool. The problem is that it is a good tool for the far simpler and more common case of trivial string key-value maps, so everyone tries to ram their pegs into that hole, regardless of shape.
As far as it being easy to consume goes, if we're in the browser, DOMParser is right there - it's a one-liner to get a DOM out.
This annoys me more than it probably should. But it also annoys me that XML didn't inherit `</>` as a generic closing tag from SGML. That would have gone a long way towards satisfying people who think XML is too verbose.
Probably it’s the (JavaScript-native) object model, not the parsing? XHR appeared in IE 5 as a part of MSXML and thus had XML handling built in, and probably every other browser that copied it included that part as well... (not feeling up to browser archaeology at the moment, sorry). But unadorned XML DOM is just unpleasant to deal with.
To some degree, YAML seems to be liked because of the very same feature of Python: Scoping via indentation. However, I'm not sure about that.
XML is akin to space shuttle. Complicated but, well thought out. Well designed for its mission, robust, but somewhat clunky. However, it's a much more accessible member of "software engineering for the enterprise" era.
These features are not fit for today's "fast" software engineering. Who'll parse that XML, yet alone verify it? Who'll write the callbacks? Or is a DOM parser better? Today people "don't have time for that (TM)".
On the more realistic side, XML is really useful and robust. Yes, it's not as fast to implement, but it's forgettable. Add a DTD verification step, then parse away. After ironing the kinks out, your parser can outlive Voyager probes, maybe even humanity itself. But it's overkill for most "move fast, break things" projects of today.
I for one, will use XML for the foreseeable future for my projects. Won't whine for consuming JSON and writing hard to understand YAML files, but if I'm going to exchange big, important data and store it on disk, it'll be XML.