I am a pedal-to-the-metal kind of guy; I always want to see the guts of the technology I’m using. That’s probably why I like Charles Petzold’s WPF book – it shows you the platform from inside out, starting with code only and later moving to the (manual) XAML authoring.

Most of the people, especially designers, will never want to edit XAML by hand. This is quite similar to the way you’d author Web pages – mostly people don’t want to learn HTML. But if the editor is a leaky abstraction you might almost be better off doing everything by hand.

Ergo, we all need a decent editor that will cover most of everybody’s needs. Building a flow layout based editor is a serious task. I once built one flow based engine, quite simpler than the XAML (mine was a subset of XUL) and when the time came to build an editor, I had to resort to generating a tiny subset of markup the engine is capable of supporting. If I tried to implement a full editor I would have spent months if not years building it.

Because of this I understand completely why the authoring tools by Microsoft are not following immediately post WPF/.NET 3.0 launch date – building these tools is hard. Additionally, some of the markup I saw before that looked horribly inefficient was not the markup produced by a Microsoft tool but the result of conversion from a general vector drawing tool.

I am happy to report that some of the newest demos of Microsoft’s Blend (the app formerly known as Sparkle) look great. The tool has come a long way and is shaping up to be the tool for XAML authoring. Current version is beta 2, runs on the RTM release of .NET 3.0 and is free to use for up to 6 months.

My recommendation still stands – if you’re a developer, learn the technology first, author a few XAML files by hand, then jump to the tool. When the time comes (and it sure will) to dive into XAML, you won’t have issues with that. But don’t get stuck with manual XAML editing forever – use a power tool like Blend, it’s worth your attention.