2013 m. spalio 4 d., penktadienis

9 reasons not to use XML

When I have to write code that deals with XML, at some point I wish it did not exist...

NOTE: I don't say "don't use XML", I say "think twice before doing so", because simple things should be simple (and XML is unlikely to keep them simple).

Reason for writing this: I've been working with Windows 8 tiles for over two weeks, I need to release some steam...

  1. XML is for storing data, not writing code
  2. Yes, this one is dedicated for Spring, Struts, Ant, Maven and co. You can call it "declarative", "configuration" or anything else, I say "it's code". And XML is terrible for writing code: difficult to read, a lot of extra characters to write... Maybe it's easier to parse, but since when do we design language for compiler/interpreter programmers?
    BTW, you can step through the code using debugger...
  3. It's very difficult to manipulate without dedicated library
  4. Libraries exists, more than enough of them. But quite often modifications you have to make are so trivial, that simple text find&replace seems to be the best solution. But you can't do that, because you have to make sure the string you put to XML does not have characters <, >, ", /, &,... Simply to many of them and who can tell them all without looking somewhere? So, no tools like sed or string methods like replace() for you, use fully featured library to change those two attributes...
  5. It's hard to work with even using dedicated library
  6. Marshaling objects to XML or unmarshaling from is fairly easy, full-featured frameworks are available for this. But it gets more interesting, when you only want to change a couple of nodes and XML document is not made by you. Doing full marshaling is not reasonable: a lot of code and bad performance. To add/remove node or set attribute is not as trivial as you'd wish. Simply string find&replace is out of question, while searching for nodes is either fragile or requires quite a lot of checking. Debugging such code is never fun.
    The only simple way I've seen is manipulating dom in JavaScript, but you're not always lucky to use such dynamic language. With C++, C# or Java this is much more messy...
  7. Slow to read, slow to write
  8. Complex syntax make XML parsers slow compared to the ones for other formats. Formats like JSON or YAML are faster in this respect as well as they are more human-readable. Not to mention simple key-file or INI file formats, which are enough way more often, than they are used. And they are easier to parse by hand than it is to read XML using library...
  9. It's only suited for tree-like data
  10. If data is of simpler structure than tree, say, list of records, XML is too complicated for it. Record-Jar format is more suited for this. The same applies for data, that is more complicated than tree, like graph.
  11. Too powerful for most use-cases
  12. What is the difference between child node and attribute, when to use one or another? Do you need entity reference? Do you need schema validation? Do you need XSLT?
    When you look at what you need and answer "no" to almost every advanced feature, why mess with this format at all?
  13. Difficult to embed into program code
  14. Most C-based programming languages use double-quotes for strings, which are also used for attributes in XML. Happy escaping!
  15. But everyone knows it
  16. That's a valid argument. But you can also say that everyone goes to dentist, so it should be something everyone likes... The fact that XML is industry standard does not make it good, it only means that industry chose this format because they though it was better than alternatives at the time. It does not mean that it still is and it does not mean it is good for the problem you are solving ATM.
  17. XML for UI: from nice to ugly
  18. UI is one place where XML has proven to work well. No surprise, UI is tree-like, so XML just fits right here. More - widgets have properties and children, so attributes and child nodes do the right thing. Application supports plugins? Several XMLs can be merged, Firefox is a good example. Web pages are XML (well, almost), etc.
    Now about the ugly part. Do you manipulate raw XML in the code? Tiles in Windows Store Apps require XML for notifications and badges. The first is ugly - you get predefined template and manipulate it using XML manipulation classes to insert necessary attributes. With badges it's much, much worse. They only support numbers and predefined glyphs (identified by string constants!), but to put a badge you have to prepare the full XML document! F*** you very much.
And now the enterprise hell falls onto my head...

Komentarų nėra:

Rašyti komentarą