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? 😛 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.
I fear the persistence of this idea – that XAML goes via C# and then IL – may be my fault…
That was actually the default behaviour for the XAML compiler in the PDC03 timeframe version of Longhorn. It would generate C# code that built up the object model. I think this was referred to as CAML at one point. You could switch to BAML by choosing the ‘optmize for download’ feature.
But Microsoft realised that CAML was rarely useful. Often the overheads of loading more IL and JIT compiling it were worse than the overheads of interpretting BAML, which turns out to be pretty efficient. And even in the cases where it was a win, I think it looked kind of marginal, and not worth the overhead of maintaining an extra XAML->objects mechanism. So they dropped support for CAML.
If I’d known that was going to happen I’d probably have written my article on how XAML works up on O’Reilly’s ONDotNet site differently. 🙂 It explains the XAML->CAML process and doesn’t even mention BAML.
Have we really come very far from these days?
IDD_MFCTEST_DIALOG DIALOGEX 0, 0, 143, 49
STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_MINIMIZEBOX | WS_POPUP |
WS_VISIBLE | WS_CAPTION | WS_SYSMENU
FONT 8, “MS Shell Dlg”, 0, 0, 0x1
PUSHBUTTON “My Button”,IDC_BUTTON1,21,16,96,18
XAML is a nice, evolutionary step, for sure, but what was wrong with the WinForm method of describing the layout in the code? I suppose I’ll have to learn more abou WPF to see what all the hype is and why it’s so much better. Apparently, the folks at MS feels it’s best we separate layout from code (once again).
Thanks for the clarification…
Surely a language can be a proper language even if a particular compiler for it does translate to another language first.
Aspects of language design – like for example turing completeness – are factors that should be looked at when deciding whether something is a language or not. Not the precise process it’s executed.