Why the tech community rejected XML

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com


Java was a very limited language, and it was extremely verbose. There were type declarations and coersions everywhere. Almost all looping was managed with for loops (there were no higher order functions, and recursion wasn’t tail cail optimized… also there was no loop-recur macro…).

So XML wasn’t just there to be data, it was also code.

Everyone wrote little mini-languages into XML, because some things were so damn painful to express in Java that it was easier to just implement a small interpreter in Java for XML. The XML sections of Java projects become massive often dwarfing the Java code on the project. I’ve worked on projects that had more than 10x as much XML as Java code, and I don’t think my experience was an outlier.

So, when people started writing their code in XML, they essentially threw out all the protections they had for their compilers, and wound up using the most buggy, leaky little DSLs that ever were.

And even worse, they were damn near impossible to read, because it was XML. XML is not easily readable. It has duplication baked in as you have to declare the name of each node twice. It didn’t just map simply to S-expressions, because attributes were a thing.

As it became more and more ungainly and difficult to work with, people started throwing clever little jQuery-like libraries at it to make it simpler. Libraries like XPATH and others that were all quite complicated and had a learning curve all their own. And of course lots of companies had their own little DSLs that did the same thing as standardized libraries like XPATH but were really buggy and screwed up but were so ingrained in the project that removing them was seen as a non-option.

In short, the problem with XML was that XML was code as data as code implemented in the worst possible way. It was there to fix a lack of expressivity in the host langauge Java, and it was baked into a Markdown Language with its own compexities and subtle rules. XML was not a first class entity in Java either, so its manipulation was painful as hell. You couldnt just embed a little XML in your class, you had to read a fucking file in using the horrible decorator based input/output system in Java…

Things got a lot easier when people moved to JavaScript and JSON, both because JavaScript is more expressive and JSON is far simpler than XML to read and manipulate programatically. And they got easier again for me when I moved to Clojure. 95% of the things I might have used XML for in the past can be done in Clojure without dropping into a code as data approach, and when I do try some kind of code as data approach, its usually just writing a little literal edn that gets parsed by a function.

and also:

In concrete terms, sure, XML (and YAML etc.) all tried to capture
logic which failed, that isn’t what is being recommended in Clojure.

(if (some-pred? a) (do-this a) (do-that a))

is code that can be treated as data. Where it would go horribly wrong is if you started trying to impose a DSL on top of this:

:predicate #(some-pred? a)
:predicate-match #(do-this a)
:predicate-fail #(do-that a)

which is analogous (I think) to where XML etc. went down the rabbit hole.