XAML is essentially a subset of XML. One of the main benefits of basing XAML on XML is said to be that it can be parsed with existing tools. And it can, to a large degree, although the (syntactically non-trivial) attribute values will stay in text form and require further parsing.

There are two major alternatives to describing a GUI in an XML-derived language. One is to do what WinForms did, and describe it in real code. There are numerous problems with this, though it’s not completely advantage-free (a question to compare XAML to this approach). The other major alternative is to design a completely new syntax specifically tailored for the task at hand. This is generally known as a domain-specific language.

So, in hindsight, and as a lesson for the future generations, was it a good idea to base XAML on XML, or would it have been better as a custom-designed domain-specific language? If we were designing an even better UI framework, should we pick XML or a custom DSL?

Since it’s much easier to think positively about the status quo, especially one that is quite liked by the community, I’ll give some example reasons for why building on top of XML might be considered a mistake.

Basing a language off XML has one thing going for it: it’s much easier to parse (the core parser is already available), requires much, much less design work, and alternative parsers are also much easier to write for 3rd party developers.

But the resulting language can be unsatisfying in various ways. It is rather verbose. If you change the type of something, you need to change it in the closing tag. It has very poor support for comments; it’s impossible to comment out an attribute. There are limitations placed on the content of attributes by XML. The markup extensions have to be built "on top" of the XML syntax, not integrated deeply and nicely into it. And, my personal favourite, if you set something via an attribute, you use completely different syntax than if you set the exact same thing as a content property.

It’s also said that since everyone knows XML, XAML requires less learning. Strictly speaking this is true, but learning the syntax is a tiny fraction of the time spent learning a new UI framework; it’s the framework’s concepts that make the curve steep. Besides, the idiosyncracies of an XML-based language might actually add to the "needs learning" basket.

Are these disadvantages outweighted by the ease of parsing? Should the next cool framework continue the tradition, or invest the time to design an awesome DSL that can’t be parsed by existing tools and whose syntax needs to be learned by everyone?

P.S. Not everyone confuses XAML and WPF, but some do. XAML is the XML-like thing. WPF is the framework with support for bindings, theming, hardware acceleration and a whole lot of other cool stuff.

  • 3
    Yes, it can be parsed by an XML parser, but not meaningfully / completely. For instance, it uses string attributes to define data sources and property mappings. Commented Mar 12, 2012 at 18:27
  • 5
    What do you propose as an alternative? Any discussion about the suitability of a particular technology would have to address suitable replacement technologies. Commented Mar 12, 2012 at 18:42
  • 2
    XAML is not without counterparts, you know. XUL, Glade and QML are all based around the same idea. I think you're singling XAML out unfairly.
    – user16764
    Commented Mar 12, 2012 at 18:57
  • 3
    I think that the biggest benefit of XAML is not that it can be parsed by XML parsers. It rather is that XAML is similar to XML, and most developers already know how to work with XML, and so learning curve is much less steep. Commented Mar 15, 2012 at 7:32
  • 2
    @JuozasKontvainis If by "work" you mean "parse it in their tools" then yes. If you mean "write a UI described by it" then the familiar syntax might look like it helps, but realistically, you still need to learn what to put inside attributes (because that isn’t XML), and that is by far the hardest thing, in my personal experience. Learning a new syntax, especially if it’s simple and well-designed, is trivial, in my opinion. Commented Mar 15, 2012 at 10:13

3 Answers 3


The only compelling reason to use XML is to establish an open data standard. XAML is the same display language used in both Silverlight and WPF; any vendor can use the same markup standard to create a display definition for their own platform, and it can be reused in Silverlight or WPF.

In the aerospace industry, we have control rooms that, thanks to the advances of computer technology, are now reasonably flexible. In the past, all the hardware was custom, unique, and very expensive; today it is all run with inexpensive, commonly-available, off-the-shelf PC's. This greatly reduces vendor lock in. However, display widgets are still written using ActiveX, because that's how it's always been done.

ActiveX requires access to Microsoft tools that are, well, obsolete. So the Air Force and the Inter-Range Instrumentation Group is coming up with a Data Display Markup Language, which is XML based. This will allow practitioners to design displays using XML markup, in the editor of their choice. Sound familiar?

Nobody argues that XML is not without its faults. But it's the best thing available for what it was designed to do, until something better comes along.

See Also
Why XML Doesn't Suck

  • 3
    Would you agree that the same reasoning applies equally well to things like, say, YACC grammar descriptions, TeX, regexes, Verilog and maybe even LISP? We came up with special syntax for each one of these. They would benefit in the same way you list in the first paragraph. Then doesn’t it follow that using XML for them would be the right thing, because XML meets the goals you mentioned? Commented Mar 15, 2012 at 22:53
  • Only XML is widely recognized as a universal data meta-standard, from which you can create as many individual data standards as you wish. To avoid muddying the waters, I have removed the first paragraph. Commented Mar 15, 2012 at 22:56
  • S-expressions never caught on as a metadata standard, maybe because nobody like all those silly parentheses. Ubiquity is the compelling factor here; all of those alternate syntaxes you mentioned can be represented in XML, if you're so inclined. Commented Mar 15, 2012 at 22:58
  • 2
    All of them can be represented in YAML and JSON too (and vice versa).
    – Timwi
    Commented Mar 15, 2012 at 23:21
  • 2
    One huge problem I see throughout this argument is that XAML isn't really data. Sure, it could just be treated as just an object graph, but this kind of thinking is probably why a lot of people don't like it and why it has such a learning curve. "hey lets go make an object graph, er, I mean a user interface". I have no idea how it could be made better, but I'm confident it could be.
    – Earlz
    Commented Feb 18, 2013 at 15:29

Your objections to XML have nothing to do with using it as a GUI description language; they are all complaints about working with XML syntax that apply equally to any form of XML.

So it sounds like you just don't like XML.

You're right, it may not be the optimal choice for editing by hand, but for a GUI description language I'd make some counter-arguments:

  1. (IMHO,) GUIs are graphical and ought to be laid out graphically. The file format isn't really that important, because you really shouldn't be editing it by hand. (Text-based is nice for source-control's sake, but verbosity isn't a problem.)

  2. Besides the parser being available, XML is also easy to validate: you can write a DTD or XML Schema and then use generic tools to tell you if your file is legal. This is going to be very useful for a GUI description language. Doing the same in JSON or YAML isn't as straightforward.

  3. If you're really unhappy with writing XAML directly, there's nothing preventing you developing a new format and then compiling that into XAML. For example, you could come up with a straightforward mapping from JSON to XAML, so you can have its JSON's lighter syntax (and the ability to comment-out attributes), and then generate the XAML when you build your app. People rarely write HTML directly any more, but HTML is still a great format.

  • 1
    I do like XML; I just don’t like writing it by hand. 1. Yes, they ought to, but alas the reality is that Visual Studio can’t really pull that off. 3. This is orthogonal to the discussion of whether XAML was, in hindsight, a bad idea. Yes, one could, but why would one need to if XAML was not a bad choice? Commented Apr 3, 2012 at 8:51
  • 1
    My point is that you are judging it entirely against the criteria of writing it; your concerns have to be balanced against validating and interpreting it too. A DSL that was nicer to write would almost certainly be harder to parse. But an intermediate compilation step could give you the best of both worlds.
    – benzado
    Commented Apr 3, 2012 at 12:16

This question is subjective, so I think it is fair to post an answer that is based on my personal preference.

XML is hard to read. For example, open this link and click "Sample" to compare XML and YAML side by side. The latter is clearly much more human readable.

If you want to use XML to describe a GUI, then you better be damned sure that you provide sufficient tools so that humans will not have to look at the XML.

Clearly XPF has failed in that regard.

Not the answer you're looking for? Browse other questions tagged or ask your own question.