Part of the problem was it came in an era before we really understood programming, as a collective. We didn't even really know how to encapsulate objects properly, and you saw it in poor database schema designs, bizarre object inheritance patterns, poorly organised APIs, even the inconsistent method param orders in PHP. It was everywhere. Developers weren't good at laying out even POCOs.
And those bizarre designs went straight into XML, properties often in attributes, nodes that should have been attributes, over nesting, etc.
And we blamed XML for the mess where often it was just inexperience in software design as an industry that was the real cause. But XML had too much flexibility compared to the simplicity of the later JSON, meaning it helped cause the problem. JSON 'solved' the problem by being simpler.
But then the flip side was that it was too strict and starting one in code was a tedious pita where you had to specify a schema even though it didn't exist or even matter most of the time.
The hard truth is that XML lost to the javascript-native format (JSON). Any JavaScript-native format would have won, because "the web" effectively became the world of JavaScript. XML was not js-friendly enough: the parsing infrastructure was largely based on C/C++/Java, and then you'd get back objects with verbose interfaces (again, a c++/java thing) rather than the simple, nested dictionaries that less-skilled "JS-first" developers felt at ease with.
It's a dumber format but that makes it a better lingua franca between all sorts of programming languages, not just Javascript, especially if you haven't locked in on a schema.
Once you have locked in on a schema and IDL-style tooling to autogenerate adapter classes/objects, then non-JSON interchange formats become viable (if not superior). But even in that world, I'd rather have something like gRPC over XML.
A dumber format works great for dumber protocols like RPC. When you're trying to represent something complex like a document, JSON is crap. Imagine the JSON equivalent of HTML. Then imagine editing it by hand.
"Data" lives on a spectrum of simple to complex; most is simple; JSON is great for that. But not for everything.
> When you're trying to represent something complex like a document, JSON is crap.
I agree, but let's be honest, how often does this actually come up for data interchange. Because the situations where you want a human-editable document that is also computer-legible are fairly few in number. Prose in office documents, human-written documentation for code, config files.
For things where computer programs are driving the show (which is most the time, today), you want interchange designed for programming languages, whether that's JSON, CSV, gRPC, or what have you.
This even applies to documents that are completely computer-generated: get the inputs into an appropriate data structure using easy interchange formats, and then render to the output document (HTML, XML, LaTeX, etc.).
> Data" lives on a spectrum of simple to complex; most is simple; JSON is great for that. But not for everything.
Fully agreed. But even where you do have documents, XML is not always the right thing either, which is why there are other markup formats in wide usage like TeX and Doxygen/Javadoc-style comments. XML seems best aligned to things like office document formats or other rich text where it makes sense to want to wrap some human text inside some computer-visible markers.
> how often does this actually come up for data interchange
Pretty much anywhere with text-heavy payloads? It's quite a lot, I think, but still dwarfed by the number of cases where system A needs to perform some sort of RPC-like communication with system B.
I just think that there is plenty of room in the world for both approaches.
I think the reason is that it solved the "problem" of integrating XML into JavaScript, as if being good at XML was an end in itself. Once XML started being replaced by JSON in earnest, what was the pressing need for E4X? Doing stuff in SOAP or WS-* presumably, but that wasn't a common use case in browser JavaScript, though it might have come in handy if Node.js took off a bit earlier.
JSX took off because it helped frontend developers solve problems outside of JSX. Look at examples of its use and it's heavily intertwined with the rest of what you'd see on a webpage (HTML, JS and CSS), and you never get the sense that JSX is a "self-licking ice cream cone".
This is the abstract idealism I was talking about: Every pro-XML person I've talked to wants to discuss XML in the context of a hypothetical perfect world of programming that does not exist, not the world we inhabit.
The few staunch XML supporters I worked with always wanted to divert blame to something else, refusing to acknowledge that maybe XML was the wrong tool for the job or even contributing to the problems.
And those bizarre designs went straight into XML, properties often in attributes, nodes that should have been attributes, over nesting, etc.
And we blamed XML for the mess where often it was just inexperience in software design as an industry that was the real cause. But XML had too much flexibility compared to the simplicity of the later JSON, meaning it helped cause the problem. JSON 'solved' the problem by being simpler.
But then the flip side was that it was too strict and starting one in code was a tedious pita where you had to specify a schema even though it didn't exist or even matter most of the time.