There exists a peculiar amnesia in software engineering regarding XML. Mention it in most circles and you will receive knowing smiles, dismissive waves, the sort of patronizing acknowledgment reserved for technologies deemed passé. “Oh, XML,” they say, as if the very syllables carry the weight of obsolescence. “We use JSON now. Much cleaner.”
You must log in or # to comment.
The fact that json serializes easily to basic data structures simplifies code so much. Most use cases don’t need fully sematic data storage much of which you have to write the same amount of documentation about the data structures anyways. I’ll give XML one thing though, schemas are nice and easy, but high barrier to entry in json.
There exists a peculiar amnesia in software engineering regarding XML
That’s for sure. But not in the way the author means.
There exists a pattern in software development where people who weren’t around when the debate was actually happening write another theory-based article rehashing old debates like they’re saying something new. Every ten years or so!
The amnesia is coming from inside the article.
[XML] was abandoned because JavaScript won. The browser won.
This comes across as remarkably naive to me. JavaScript and the browser didn’t “win” in this case.
JSON is just vastly simpler to read and reason about for every purpose other than configuration files that are being parsed by someone else. Yaml is even more human-readable and easier to parse for most configuration uses… which is why people writing the configuration parser would rather use it than XML.
Libraries to parse XML were/are extremely complex, by definition. Schemas work great as long as you’re not constantly changing them! Which, unfortunately, happens a lot in projects that are earlier in development.
Switching to JSON for data reduced frustration during development by a massive amount. Since most development isn’t building on defined schemas, the supposed massive benefits of XML were nonexistent in practice.
Even for configuration, the amount of “boilerplate” in XML is atrocious and there are (slightly) better things to use. Everyone used XML for configuration for Java twenty years ago, which was one of the popular backend languages (this author foolishly complains about Java too). I still dread the massive XML configuration files of past Java. Yaml is confusing in other ways, but XML is awful to work on and parse with any regularity.
I used XML extensively back when everyone writing asynchronous web requests was debating between using the two (in “AJAX”, the X stands for XML).
Once people started using JSON for data, they never went back to XML.
Syntax highlighting only works in your editor, and even then it doesn’t help that much if you have a lot of data (like configuration files for large applications). Browsers could even display JSON with syntax highlighting in the browser, for obvious reasons — JSON is vastly simpler and easier to parse.
God, fucking camel and hibernate xml were the worst. And I was working with that not even 15 years ago!
I never understood why people would say JSON is superior, and why XML seemed to be getting rarer, but the author explains it:
XML was not abandoned because it was inadequate; it was abandoned because JavaScript won.
I’ve been using it ever since I started using Linux because my favorite window manager uses it, and because of a long-running pet project that is almost just as old: first I used XML tools to parse web pages, later I switched to dedicated data providers that offered both XML and JSON formats, and stuck to what I knew.
I’m guessing that another reason devs - especially web devs - prefer JSON over XML is that the latter uses more bytes to transport the same amount of raw data. One XML file will be somewhat larger than one JSON file with the same content. That advantage is of course dwarved by all the other media and helper scripts - nay, frameworks, devs use to develop websites.
BTW, XML is very readable with syntax highlighting and easily editable if your code editor has some very basic completion for it. And it has comments!
You are clearly one of those people that never had to deal with xml in a production system. Even with proper syntax highlighting, dealing with xml is a nightmare, whether it’s for configuration or data transmission. People switched to JSON because it’s better. Period. And that’s an incredibly low bar to set, because I don’t think JSON is that good either.
Like another person said, all of these features of XML doesn’t make it nicer, it makes it worse, because it means you have to be ready for any of those features even if they’re never used.
It’s true, though, that JSON is just better for most applications.
Except config files. Please don’t do config files in json.
Why not? It works great in Python.
Not on the human parser side.
And no comments, unless you use a non-standard parser. But then you might as well use anorher format.
{"comment": "Who says you can't do comments in JSON?"}Now do a second comment.
IMHO one of the fundamental problems with XML for data serialization is illustrated in the article:
(person (name "Alice") (age 30))
[is serialized as]<person> <name>Alice</name> <age>30</age> </person>Or with attributes:
<person name="Alice" age="30" />The same data can be portrayed in two different ways. Whenever you serialize or deserialize data, you need to decide whether to read/write values from/to child nodes or attributes.
That’s because XML is a markup language. It’s great for typing up documents, e.g. to describe a user interface. It was not designed for taking programmatic data and serializing that out.
This is your confusion, not an issue with XML.
Attributes tend to be “metadata”. You ever write HTML? It’s not confusing.
JSON also has arrays. In XML the practice to approximate arrays is to put the index as an attribute. It’s incredibly gross.
In XML the practice to approximate arrays is to put the index as an attribute. It’s incredibly gross.
I don’t think I’ve seen that much if ever.
Typically, XML repeats tag names. Repeating keys are not possible in JSON, but are possible in XML.
<items> <item></item> <item></item> <item></item> </items>That’s correct, but the order of tags in XML is not meaningful, and if you parse then write that, it can change order according to the spec. Hence, what you put would be something like the following if it was intended to represent an array.
<items> <item index="1"></item> <item index="2"></item> <item index="3"></item> </items>
The same data can be portrayed in two different ways.
And that is issue why? The specification decided which one you use and what do you need. For some things you consider things as attributes and for some things they are child elements.
JSON doesn’t even have attributes.
