I recently answered a question something like the one above for an Australian developer mailing list, but I know this question isn’t unique to Australian developers, so I figured I’d post my take here for a broader audience. Hopefully this is interesting or relevant!
Whenever we talk about Avalon and XAML together, it’s important to understand the distinction between the two. Avalon is our strategic next generation graphics subsystem, based on Direct3D. On the other hand, XAML is a markup language for succinctly describing a hierarchy of instantiated CLR objects and properties. It’s true that XAML came out of the Avalon team, but there’s no hard-wired link between the two. In theory at least, you could use XAML to construct Windows Forms UI; in fact, the Windows Workflow Foundation technology just announced their plans to support XAML for building workflows. Turning this around the other way, everything you write in XAML could alternatively be written in any other .NET language. If you don’t want to use XAML, then that’s fine by us – use C#, VB or even COBOL if your perversions run that way. So it’s simplest to think of Avalon and XAML as two completely separate technologies that just happen to have been introduced at the same time.
So having cleared that up, we can now address the question of why XAML at all. For me, there are really two benefits, both inter-related.
Firstly, XAML is toolable. Because it’s good old XML, it’s really easy to parse and manipulate by any application. Compare this to Windows Forms, which in its 1.x incarnations litters your own classes with those nasty #region areas that attempt to scare you away from editing them. Even in 2.0, the same code is present, but at least with the benefits of partial classes it can be squirreled away into a more obfuscated location. The impact is that the only Windows Forms designer available is Visual Studio (I’m being a little unfair to the likes of SharpDevelop, but you get my point – it’s a lot easier to work with XML programmatically than with code).
Tools support means that we expect to see a really big new ecosystem open up around building UI with XAML. Even at this early beta stage, we have Mobiform Aurora, Electric Rain ZAM 3D, Expression “Acrylic” and “Sparkle”, and an Adobe Illustrator plug-in. Perhaps just as important, some early adopter customers are using XAML to build UI on the fly, exactly as Nick mentioned below. (Check out the Parser.LoadXml() method for one example of how to do this.) For example, you could use this to generate a complex display based on data that came from a database. We’ve also reintroduced the concept of Loose XAML in the latest Avalon CTP – this allows you to double-click on a XAML file and load it directly in the browser without compilation.
The second big advantage of XAML is the design / code separation. Having an environment where the .xaml and .xaml.cs (or .xaml.vb) files are separate means that you can truly enable both designers and developers to share the construction of an application. Most designers don’t make good coders (and indeed, don’t see themselves as developers). The reverse is also true; whilst I know some developers who care deeply about good UI design and are artistically talented enough to produce a polished application, I also know some developers who shouldn’t be allowed Paintbrush on their system! Avalon brings peace and love to this situation by allowing designers and developers to each use their own preferred tools and focus on their strengths. Some people buy into this more easily than others, particularly those coming to Avalon from the Macromedia Flash world (which has had a much stronger designer emphasis than, say, Windows Forms). Certainly when you see applications such as Microsoft Max, you see an example of the benefits of good design.
In the next year or two, we’re going to see tools that are targeted at developers, and tools that are targeted at designers. Expression “Sparkle” is a good example of a designer tool – it has pitiful code editing support and doesn’t look anything like Visual Studio. That’s a good thing, because its target audience is not we developers. “Sparkle” is great on the other hand for things like animation storyboards and 2D and 3D vector graphics creation. On the other hand, Visual Studio “Orcas” will contain an Avalon editor that is perfect for developers – great data binding, IntelliSense, forms editing, code-behind. Both these environments will work well together as part of a synchronized workflow. In most cases, the designer will construct a rough UI layout which they will pass over to the designer as XAML. The developer can work on all the back-end logic, web services, data binding, UI workflow etc. whilst the designer polishes the design. Since the XAML (UI specification) and the C# or VB (application logic) are separated, it allows for parallel and shared development without forcing anyone to adopt an unfamiliar paradigm.
Lastly, I know some people wonder why we didn’t simply evolve Windows Forms and/or GDI rather than creating a brand new subsystem. It’s interesting to note that GDI is now close to celebrating its twentieth birthday – whilst it has undergone many revisions over that time, many of the fundamental APIs are still direct descendants of those used in Windows 1.0. And there’s been so much change over that time – in the last three years alone, graphics cards have increased tenfold in performance for the same price. Many of the most compelling features would be almost impossible to add to GDI: for example, logical pixels, resolution-independent vector graphics, 32-bit ARGB color space, double-buffered animation, separation of layout from rendering, and orthogonal 2D / 3D APIs. To hopefully hammer this point home, take a look at the North Face In-Store Explorer Prototype (MSDN whitepaper) to see an application that couldn’t have been written in any reasonable time period with any other technology.