Paddock on WPF/XAML: the Good, the Bad, and the Ugly – Revisited
Manual XAML Coding Required
Rod Paddock: Out of the box you are still required to hand code your XAML. Cider (discussed below) is a weak tool for doing layout and provides very limited control of your XAML form development. Aurora (mentioned above and below) is a better tool than MSFT’s offering.
The Cider team still does have a lot of work to do, I agree. But I’m confident that they are headed in the right direction and will end up with the right tool for VS users.
I’m happy to see that we have 3rd parties like Mobiform also providing tools. That is a great thing.
In addition, Expression Interactive Designer is closer to their v1 ship goal than the Cider team is, so please be sure to consider it.
Weak Background Compilation of XAML
Rod Paddock: When you manually code your XAML your controls don’t consistently show up in the code behind. In other words if you add the following control <TextBox ID="txtLastNane"> you won’t see this object in code behind files Intellisense until you manually compile your code.
Rob Relyea: Yes, this work needs to be done in real VS "Orcas" (instead of just the tech previews.) This is an understood problem.
XAML Specification Fluidity
Rod Paddock: The specification and underlying technologies for WPF and XAML seem to be very fluid in nature. Every version contains breaking changes. This is to be expected in a brand new technology like WPF. But at some time this needs to slow down. Still I feel the spec needs more revision at this point. XAML is inconsistent in a number of areas and needs more work to improve consistency.
Rob Relyea: We are changing less and less each release. Your code should take less and less time each CTP to move. We are doing fewer changes and there must be better reasons for doing them all. We are trying to only change the absolute critical things.
Rod Paddock: One of the goals of .NET was to add some level of consistency. All classes inherit from objects, have a ToString method, have a GetType method, etc. UI elements in WinForms have a Text element rather than one having a Text element and another having a Caption element (as we faced in VB6). This same careful attention to detail missed the XAML team. For instance:
Why do these two elements have greatly different markup for a common task. Either the <Button> element needs to have a Text attribute or the <MenuItem> element needs to support markup similar to the <Button> element. I think MSFT needs to look at this before they ship.
Rob Relyea: MenuItem and Button may seem similar, but MenuItem and ListBox are closer in relationship. MenuItem and ListBox are both ItemsControls – they can contain 0-n Items as children. Because the menuitem can have those children (for cascading menus), we had to have a different property for the "content" or header as we call it.
Stale Blog Code
Rod Paddock: There has been a lot of work on WPF by numerous bloggers. When you Google stuff on WPF you often come across Blog entries written for old versions of WPF. Because of the fluidity of the XAML spec these are often grossly out of date. I am guilty of this as well. I know for a fact none of my old blog entries will work with current versions of WPF. This is not the fault of the teams at MSFT just a statement of warning about old examples. Maybe we as bloggers should tag our articles on what version of WPF (or other technology) they will still work with.
Rob Relyea: I think you have a few great ideas. When people blog about WPF they should include details on the build their xaml and/or code is targetting…and people should go back and update older posts…perhaps even just a quick note that it is out of date…
I’ve started doing this recently and I’ll try to more of it.
Weak Flavored Cider
Rod Paddock: Cider at this point (based on the Feb 2006 CTP) is just plain weak. Cider is the code name for the WPF tools that integrate with Visual Studio 2005. Basically all Cider provides at this point is a mechanism for dragging and dropping controls onto a WPF form. It has some rudimentary control over properties but thats about it. This tool needs lots of work. I wouldn’t even go as far as calling this tool Alpha. Microsoft needs to reconsider putting tools out that are in this early stage of development.
FWIW there is a pretty cool UI designer tool called Aurora. Aurora is from a company called Mobiform and can be found at www.mobiform.com. From what I can tell Aurora is written in WPF. It is hands above better than Cider.
CAVEAT: I have not played with Sparkle which is a standalone XAML/WPF editor. I am looking at this from the developers standpoint and the tools that work in VS.NET. From what I have read/seen about Sparkle this technology looks pretty cool. But it is geared much more for designers and not developers.
Rob Relyea: The Cider team still does have a lot of work to do, I agree. But I’m confident that they are headed in the right direction and will end up with the right tool for VS users.
The Expression Interactive Designer ("Sparkle") team have been working on WPF longer than Cider has so far, thus the differences in the capabilities of the tools.
Documentation is Still Lacking
Rod Paddock: It is really frustrating to work with a new technology that is so poorly documented. This has been the case in the software industry for decades and I am not sure if it will ever change. In my opinion every class and its properties, events and methods should be documented with an example. I can’t understand how a company that has a specification process as good as Microsoft can keep churning out documentation that is so poor. MSFT is in the business of building tools for developers they should explain how to use them. Every specification should include an example of a properties use. These examples should change as the specification changes. Automated tools could then extract these examples from the specifications. This is much like XML comments in classes in .NET.
Rob Relyea: We do need to be better at making sure we can leverage specs, the internal community and the developer community to improve here. Meanwhile, please make sure you use the comment feature in the sdk to give specific feedback for areas that need work.
XAML is Difficult/Impossible to Debug
Rod Paddock: The compiler for XAML needs to come up with useful errors telling developers what is clearly wrong with there markup. XML namespace mismatch errors are insufficient. The XAML team needs to take a look at the VB helper technology that looks at an error and does its best to suggest a proper fix to a problem.
Rob Relyea: We realize debuggability of XAML is very poor in many cases. We are continuing to work to improve it.
Missing Grid Component
Rod Paddock: Sill ugly and MIA from all releases so far. This is still the most obviously missing component. The reaction from developers is always the same when I point out this short coming…. WHAT!?!?!?!?!?! How could they have missed that one?
Rob Relyea: Yes, sorry…not for V1.
Is WPF Ready for Prime Time?
Rod Paddock: In this authors opinion no. WPF as a technology has a number of really cool features. The Good section of this post is sure getting "Gooder" (Thanks Mr Bush J). But this technology still has a ways to go. I think some of the shortcomings will limit its adoption by mainstream developers for some time. The developer tools story needs to improve greatly. Debugging needs more work. WPF is definitely a 1.0 version and I feel its adoption will happen when its 2.0 version releases.
Rob Relyea: Luckily, work on VS "Orcas" and EID ("Sparkle") continues even as we are wrapping up our v1. We realize Microsoft and 3rd parties need to create great tools to make WPF broadly usable. Keep up the feedback so we can solidly answer yes here.
Thanks for your feedback Rod. It is always welcomed.