Log in
JSON is not a good data-interchange format.
This article is part of a series called Worse is better, in which I muse on technologies and techniques that became popular despite superior alternatives. Think VHS versus Betamax.
In this article, I will argue that XML is superior to JSON in most respects.
Lightweight XML #
Depending on how old you are, I guess that you have one of two reactions. If you started programming around 2015 you may simply ask: "What's XML?" If your programming career reaches further back, your reaction may be one of incredulity: "Oh my God, how can you say that?! Good riddance that SOAP, WS-(death)*, and XSLT are things of the past."
Indeed, and I don't miss them, either.
While that reaction is typical, it confuses cause and effect. SOAP and similar standards weren't cumbersome and overly complex because of XML. They managed to be awkward and enterprisey all by themselves. As a thought experiment, you could define all the payloads and specifications of SOAP as JSON, but it would, ironically, be even more verbose, because you'd have to invent a schema language and so on.
XML doesn't have to be heavy or formal. You may find the informality of JSON an advantage. Just write a document:
{
"author": "Peter Watts",
"title": "Blindsight"
}
While this is indeed easy and requires no ceremony, what prevents you from doing the same in XML?
<book> <author>Peter Watts</author> <title>Blindsight</title> </book>
You don't have to first define a schema. You don't have to declare a namespace. You don't have to add an XML declaration.
But you can, if you need to. XML allows gradual enhancement. If, sometime later, you find that a formal, machine-readable document specification would be useful, you can use XSD. And yes, I'm aware of JSON Schema; I hope the reader can see the irony that such a thing exists.
Sweet spots #
Like any other technology, XML is not a one-size-fits-all technology. I think the ideal scenario for XML is interoperability. While I'm aware that modern systems handle JSON as well as XML, I would still prefer XML for most data exchange tasks. The main driver for that decision would be the possibility to define document schemas. As Alexis King argues in a slightly different context, the lack of static types or, here, a machine-readable schema, does not entail the absence of a specification. Only, as suggested by Hyrum's law, the contract is implicit.
XML comes with a standard schema language, a standardized way to version documents, a standard query language, a standard for streaming parsers, etcetera. Of course, nothing prevents you from inventing similar technologies for JSON, and I'm sure someone already has. Even so, XML is a more mature format. Why reinvent the wheel?
A less ideal use of XML is for configuration files. I know I've lost that fight, but JSON is not a good format for configuration files. The most obvious problem with JSON is the lack of support for comments. And I know that various tools and editors allow comments in various proprietary formats, but it's not part of the standard. XML, on the other hand, has a standard for comments.
You may argue that XML is less readable than JSON, and I will partially agree, even though with good tools such as syntax colouring I find the difference marginal. The same goes with editor experiences. Most code editors will help you with XML to the same degree that they will help you with JSON. And again, if you work with a document that has a defined schema, the editor can help you more by suggesting and auto-filling elements.
But really, neither XML nor JSON are perfect configuration file formats. I wonder if such a thing even exists.
Where JSON shines #
Where would I choose JSON? To be clear, I would pragmatically choose JSON in lots of cases today, simply because that's the expected format, and having to defend a less popular choice is rarely worth it.
Ironically, the kind of architecture we today call SPAs got started as AJAX, where the X stood for, you guessed it, XML. Even so, the J stands for JavaScript, so it makes more sense to use JavaScript Object Notation (JSON). That's what modern SPAs do, and I would too, particularly if the service in question was a BFF.
Size #
I'd be surprised if you've made it so far and haven't though of size as a factor in favour of JSON. It's true that XML is more verbose than JSON. Depending on the actual schema and payload, the size difference could conceivably be more than a factor of two; compare <die><roll>4</roll></die> (25 characters) to {"roll":4} (10 characters). On the other hand, for other kinds of payloads, the difference might only be a small percentage.
In my experience the size difference doesn't matter that much. Often, other factors also play a role: Network latency for transmission, or block size for storage. And when performance really is a consideration, JSON may be too big, too.
Conclusion #
Although XML is generally and unfairly loathed as an old-fashioned legacy or enterprise technology, in most aspects it's a format superior to the more popular JSON.
XML has a rich ecosystem of mature standards, including a schema language that even supports sum types. While you could reimplement many of these in JSON (which has already been done), why reinvent the wheel?
Next: Worse is better: C# versus F#.
This blog is totally free, but if you like it, please consider supporting it.
