Posted on 4/26/2010 8:54:22 AM by Justin Etheredge
Just the other day I put a tweet out on Twitter where I exclaimed that I am not a fan of XML based build systems. Yes, I understand their purpose, and yes they were great in their time, and yes I still use them on almost a daily basis, but I really think that we have better ways that we could be doing this. The most common response from my tweet was “but was is the alternative?” And I thought, yeah, one of the most important things that I have learned in my lifetime is that you never complain about something unless you have a solution. And so I am here today to propose to you a solution…
The Problem With XML Based Build Systems
Before we get into this entire discussion, let me ask you a question… what is it that developers do better than anything else? Got your answer? Well, I know what mine is, and that answer is “write code”. And if that is the case, then why are we so intent on shoving things into giant xml files? Why can’t we write code? The usual argument is that XML based applications allow us to more easily make changes without recompiling, they allow for more flexibility, and they make it easier to write tooling since they are based on a format that everyone can parse. But personally, I don’t think that they offer much value, and instead are the project of the XML hysteria that swept through the programming world a few years ago. In fact, those of us who have been working with these XML based build tools for years probably forget just how ridiculous and obtuse they looked when we first saw them.
So while many people are quick to extol the virtues of XML, they often people forget to point out all of the things we lose when we start writing code in XML. For example, how about all of the tools that our industry has spent so many years crafting and refining. We lose our editors, debuggers, libraries, and all of the other tools that we use in order to get a few minor advantages that XML provides us. Those XML files limit us to the degree where we often find ourselves falling back to writing custom tasks in order to get around those limitations. Custom tasks which are not written in XML, but instead have to be written in code, since after all, the XML in these files is really just a hideously complex configuration system for the code which is actually running underneath.
Continue reading the rest of this post...