Monday, October 03, 2005

Battle of the Windows Presentation Technologies

Since the Windows Presentation Foundation (Avalon) will be available on XP, one of the things I hear people struggle with is the decision of whether or not to use Avalon or Windows Forms for their presentation layer given that they plan to ship their product in a time frame later than Windows Vista and WinFX.

It's pretty clear that longer term, say in the 10 year time frame, that Avalon will be the dominant presentation technology but over the next few years, things are a bit more gray.

In fact, there has been a lot of blog activity with regards to Windows Forms vs. Avalon. Some of these articles are getting dated but here are some summaries of what is out there:

Mike Harsh asks "Is Windows Forms Dead?"


  • Asserts that Whidbey will be the last full featured version of Windows Forms.
  • Windows Forms is hitting the ceiling on what Win32 can accomplish
  • The Windows Forms team is focusing more on infrastructure that is independent of the presentation technology (i.e. ClickOnce and configuration)
  • Worth investing in Windows Forms today and next year since VS.Net 2003 and VS.Net 2005 are the most efficient ways to build Windows applications in that time frame
  • Worth investing in Windows Forms in 2 years? Judgment call, if you only need to support XP and Vista, then Avalon is the way to go.
  • Simple to integrate Windows Forms with Avalon controls
  • Because of the Windows Forms support for Avalon and Avalon support for Windows Forms, there isn't going to be a need to rewrite a Windows Forms UI in Avalon -- can make incremental changes.

My take:

I'd be a little disappointed if Whidbey was the last full featured version of Windows Forms. I think that similar to the new ToolStrip controls that there can be a lot of work done to provide richer controls.

Although Avalon brings a lot of capabilities around whiz bang type UIs by utilizing DirectX, one of the main reasons I hear people want to move to Avalon is to change the UI development model. (think business and productivity apps where video backgrounds and 3D don't have a value proposition) A lot of companies want to get the developers out of the UI implementation business and put it in the hands of the experts in that area -- UI Designers.

In other words, the key to XAML is the tools that support it. As Don Box indicates here, he believes that the number of people who will create and edit XAML using a text editor will be statistically zero.

If getting developers out of the UI implementation business is what you want to do then you want to consider how the tools available will support building your UI in the time frame you need. Additionally, you need to think about how the Windows Forms to Avalon transition will map to your UI development model changes.

Dan Appleman "Windows Forms to Developers: I'm not dead yet"

  • Because Windows Forms wraps the Win32 API, it has much less of a learning curve than Avalon since every Windows developer in the world is familiar with the Win32 API. Do the features Avalon promise justify learning the new Avalon API?
  • Believes the transition to Longhorn/Avalon will be slow as there is no compelling economic advantage.
  • Windows Forms suffers the .Net distribution issue and Avalon will suffer that as well as limited OS support

My take:

I believe the API is secondary, developers love learning new things... at least the architects and tech leads that get to decide which technologies to use do. Changing the development model to have UI implementers will also play a role in the adoption of Avalon.

Ultimately, the features and declarative programming model in Avalon need to justify, not only learning the new API but also the Windows OS value proposition. As AJAX and DHTML start coming close to the power of Win32, the Windows presentation layer has to raise the bar.

The question is: when will Avalon be able to raise that bar while also having the productivity that Windows Forms has for building business and productivity applications?

More on XP vs. Longhorn discussion

  • Can Avalon run on XP?
  • LDDM (Longhorn Device Driver model) different from XPDM, concerns about the stability of the DirectX drivers under the XPDM. These drivers were written for gaming, not for the everyday use on the desktop.
  • Inability to tweak User32 on XP. Won't be able to treat legacy content (i.e. Win32) the same way as Avalon content like you will be able to on Longhorn
  • Terminal Services and Remote Desktop - planned on handling that differently with Avalon.
  • Avalon was relying on the Longhorn Media decoding system. May not be available on XP.
  • Desktop window manager will be available on Longhorn only

My take:

This article is slightly off topic but it highlights the point that you need to ensure that if you plan to use Avalon on XP that you do your homework with regards to where it doesn't work the same as Longhorn. Windows Forms will be consistent across those platforms...

Another thing to consider is what the Avalon minimum system requirements will be. I don't believe Microsoft has announced this yet but the beta 1 requirements are 512 MB RAM and a DirectX 9.0 compatible graphics card. XP shipped in 2001 and the majority of those machines will not fulfill those requirements. In other words, if you are considering on using Avalon, you better understand what is meant by your "Windows XP support" product requirement.

Put another way: just because Avalon supports XP doesn't mean you can use
Avalon to support all of your XP customers.

Mike Henderlight asks "Can't We All Just Get Along?"

  • Avalon/Windows Forms interoperability should be viewed more as a co-existence strategy and not a migration strategy (i.e. there won't be a Windows Forms to Avalon converter in the future)
  • little parallel to the chasm of VB6 to VB.Net, Windows Forms and Avalon will support having assets from both technologies in the same executable
  • Two message loops, one for Avalon, one for Windows Forms will bring challenges
  • Goal is to support: Avalon controls on Windows Forms, launching an Avalon window from a Windows Forms app, and Avalon apps that can host Windows Forms controls

My take:

I'm really excited about the high level of support for interoperability between Avalon and Windows Forms and I really see Windows Forms as the technology of today and the bridge to the technology of tomorrow.

To me, that is one of the main reasons to continue with Windows Forms development now and then switch over to Avalon when the technology matures and the tools become available.

Of course, for completeness, I have to mention that the Windows Forms/Avalon interop scenario doesn't support the "UI designer implements the UI" model. You can have a hybrid model though and that can act as a bridge for the UI development process.

Conclusion

Ultimately, whether or not to use Windows Forms or Avalon will depend on your situation, when you plan to ship your product and your tolerance for risk.

That said, the key criteria to consider when making a choice between the two are:

  • Level of OS and hardware support required
  • Tools available for building the type of UI you need
  • Tolerance for v1 technologies
  • Tolerance for shipping an additional redistributable on top of the .net Framework (WinFX)
  • Avalon value proposition - DirectX based, declarative UI...
  • Ship date for your application
  • Skill sets of the developers

It's important to consider that Windows Forms is proven, there are large scale applications localized to 21+ languages out there using Windows Forms. For Example: Here's a case study of a large Windows Forms suite of applications that HP shipped in 21 languages.

Windows Forms will support 98 through Vista and provides a highly productive development environment. I feel it still has room to evolve as a framework and I hope Microsoft does too.

There is first class support for Avalon on Windows Forms and Windows Forms on Avalon so you can rest assured that your investment in Windows Forms will not be wasted.

My conclusion is that for most applications, Avalon will not provide enough value proposition to overcome the OS and hardware requirements, lack of tool support and risk with a v1 technology for the next 2-4 years.

Avalon is the future, there is no doubt, develop in Windows Forms now and use it to be your bridge to Avalon.

0 Comments:

Post a Comment

<< Home