The new application model in Windows Vista separates out declarative code (XAML) from procedural code (C#, VB.NET, J#, etc.). One major reason for using XAML is to bridge the gap between developing an application for Microsoft Windows and developing an application for the Web.XAML does not give you new functionality; it is just a declarative way to instantiate and initialize Microsoft .NET objects. XAML does, however, provide you with a way to solve problems such as:

When you write procedural code (C#, etc.) to create a number of controls, and compare that to the equivalent XAML, the XAML is more compact, less redundant, and less error-prone. Writing a designer for XAML will be a lot easier than writing a forms designer for C# or VB.NET, since the designer won’t have to do all that code parsing to figure out where to insert or change the setting of a property.

In the real world, many customers find requests coming in at the very last minute asking for changes to the user interface—a button needs to be moved or removed or the company logo needs to appear on every window. It is especially at the end of the development process, when you think your code is “frozen” and tested, that you’d rather not have to dive into the source code and start changing things. Who knows what subtle interaction you might break? With XAML, most—if not all—of the presentation layer is in its own file, thus providing a high degree of certainty that making a user interface change in the XAML will not break business logic code.

XAML enables professional graphic designers or user interface specialists to add beauty, style and grace to an application without modifying source files directly. Partitioning the user interface and the logic that drives it means each of us can get our job done without getting in each other’s way or having to understand the myriad details of one another’s tools.

XAML is considerably smaller than the equivalent C# code. Since there is less code, there are fewer opportunities for errors.