Richard Leggett on New Media

Aral just had an interesting post on XAML, the markup language used for presentation and layout in Microsoft's Windows Presentation Foundation (WPF). He touches upon a fact that it is sometimes quite a shock to see some real abominations when it comes to some of the XAML out there on the web. But there's more to it than meets the eye when digging deeper. I'd like to post my reply on here also, and make it clear, I am not evangelising for either side in this post, but I find it fascinating comparing these two technologies which are making modern creative development very satisfying....

<snip>

Hey Aral,

Actually I feel I should jump in and balance the arguments a little as a fellow Flash developer. I've been using XAML a lot recently, and it is such a different beast, even though there *are* a lot of parallels throughout the development process, such as timelines, styles, templates (skins), data-binding, partial classes (code behinds), bitmap effects (filters) and so on.

Please ignore the reams of un-readable XAML code out there on the Web. These are auto-generated by designer oriented tools, trust me you can write some really beautiful concise stuff if you *don't* use them. (read: Visual Studio with .NET3 "orcas" add-on if you want to pay, or Visual C# Express with addon if not).

XAML/WPF really does a brilliant job of seperating code from presentation, it positively enforces it in the way you have to work. It takes a little getting used to, true, but for someone like yourself that would be measured in hours not days. It is similar perhaps to DHTML, where the presentation is entirely seperate from the logic. This is shown by the ability to dump all visual content in say the Button class, and replace it with anything you like, it doesn't break because the visual entities are seperate from the Button's behavioural code.

The speed at which you can throw together a simple application is probably the same for both. With XAML you can put anything inside anything inside anything, this makes for some really well encapsulated "cell renderers" without requiring the concept of a cell renderer at all, it's quite clear that the framework is doing an awful lot for you to cater for lots of needs and this has it's ups and downs because it means that your aren't as "pedal to the metal" as with Flash, where we tend to know pretty well what is *actually* happening behind the wizards curtain. As usual with MS we have to rely on the engineers doing a good job on the black box and providing lots and lots of documentation, which they do to a good level.

Where Flex/Flash eases ahead is in terms of visual dynamics and other such nicities. XAML's power comes from the WPF framework behind it. You can literally add tags inside component tags to add borders of all kinds, vector graphics for background etc, dropshadows and other bitmap effects, all conforming to the chosen layout control surrounding them like VBox or Grid. This works great for applications, but if you want some of the things Flash does best, very dynamic animation and small additions here and there you need to jump through the stricter hoops WPF enforces, which means it is much much slower to do certain things and not so easy. Unlike with the Flash Player, being bred as a tool for animation, which enables you to very quickly add dynamism in very little code. This has something to do with the prototype based nature of ActionScript, but more-so the core types built into the player.

This is illustrated by a simple example. I wan't to create a button with 3 states, each looking slightly different visually. In Flash this could not be easier. But in WPF, without an IDE that actually has a concept of these states built in, you must do it in code/XAML only (perhaps also using individual vector/bitmap assets if you want)....

So in Flash it is easy, particularly with slice-9. In XAML/WPF you need to think differently and do this by setting up a new style for all buttons (or just one instance), and then putting in 3 style trigger tags within, one for mouse over, mouse down etc. In those style triggers you can replace the template/skin, or make it highlight/glow etc, it is kind of like modifying CSS on HTML entities using JavaScript on a JS event. So there's a different way of thinking required. But neither is better than the other because they both have so much to offer. The lack of a visual editor acts as a double edged sword. There is a visual editor, but it is only that, you can only create static graphics, the concept of MovieClip does not exist.

At the end of the day penetration stats are going to make the decision for most people, but all in all I thoroughly enjoy using both, and will continue to do so. The Visual Studio IDE makes me a hell of a lot more productive than with any other IDE in any other language. Just being able to use the immediate window (type in any code and it will evaluate it whilst the program is running) and a truly amazing debugger, makes WPF development a joy (roll over objects/arrays in code, have it tree-view that item at runtime). But I'd be saying the same if FlexBuilder had those features, and with the new stuff in AS3 this might possible if the object reflection has come along enough.

</snip>

Comments welcome as always, but please keep them balanced