Ryan Dawson has a couple of articles up over on Longhorn Blogs titled “XAML and C#” where he's discussing the developer experience of working in a mixed language environment for developing next generation Windows applications. In his second article he states the following, which prompted me to write this post in response:
"XAML is a language (technically this is false, since it is compiled into C# first and then into IL, but you get my drift)."
XAML is indeed a language, but it is never compiled into C# or IL. In fact, let's not even talk in terms of C# because XAML can be used from/in conjunction with any language that supplis a CodeDom implementation and some MSBuild target files. Right now Microsoft supplies these for both of their flagship languages: VB and C#. Let's get back to XAML though. The truth is, it's not "compiled" at all. If anything you can say it is "compacted" and that only happens in scenarios where it is turned into a BAML stream. That, however, is an optimization and not a necessity for XAML to work. XAML can be interpreted purely in it's raw XML text form, using Parser::LoadXml. Even BAML is interpreted, it's just a far more compact and efficient representation of the object graph than raw XML text.
The fact that any .NET language code is generated at all for WPF applications is just part of Microsoft's story for the .NET developer. Just like ASP.NET, Microsoft has applied the "code-behind" approach for WPF development. The little code that is generated is actually a partial class that basically bootstraps application and control/window initialization by loading BAML from a stream embedded in the compiled assembly. Secondarily it contains typed variables that represent the x:Name'd elements in the XAML graph and a little bit of code to initialize them when the stream is turned into an object graph. Finally, much like the variable generation, it also enables the ability to declare event handlers in the XAML that are connected up for you automagically in the initialization. In fact you'll find that you cannot apply event handlers in XAML *unless* you're compiling the code. Rob Relyea does an awesome job detailing the whole process here.
Truth is, you don't have to work with XAML this way at all. You could just as easily hand write all the code yourself for loading XAML, hooking up all your own declared variables and event handlers. Why you would do that is beyond me though... unless of course you're using MC++ to write your WPF apps? :P Different tools are bound to use XAML in different ways as well. While I haven't had time to explore it enough yet to see how exactly they do it, WWF is also going to be leveraging XAML.
As I was wrapping this post up, linking to everything, I realized Rob Relyea had already discussed the different approaches to using XAML in WPF apps. Check out this previous post for even more details. Also, please note some information might be out of date in the linked articles because WinFX has changed radically over the course of its existence. Most of the concepts around XAML have remained relatively stable though.