Mike Harsh writes:
"Please keep in mind that this is just my opinion and view from the trenches. It in no way represents the any official position.
Over the last year, whenever we'd visit customers, the Avalon question always came up. The response we repeated over and over was, "Avalon is the future and only runs on Longhorn. Windows Forms runs on all platforms down to Windows 98 and is *the* story for building managed UI on Windows for the next 5-7 years until Longhorn becomes ubiquitous".
Then came "the announcement" and the title question began to spread. Just what is the future of our team? Will there be another version of Windows Forms? Is it worth it for customers to invest in Windows Forms?
These questions, combined with a few other blog posts about the subject (Dan Appleman, Scoble, and of course Joel Spolsky) got me thinking. We’ve all been ruminating about these issues inside the Windows Forms team and the more I think about it, the future of our technology doesn’t look so bad.
Let’s start with the obvious:
From an innovation perspective, Whidbey is almost certain to be the last full-blown feature version of Windows Forms. Any post-Whidbey release is likely to contain only tactical features, bug fixes and other infrastructure to support the next version of VS that will run on Longhorn.
Is this a bad thing from a developer perspective?
I think it merits further investigation. Far too many times during Whidbey development, we bumped our heads on the glass ceiling of what Win32 can accomplish. A styling engine for controls and arbitrary nesting of controls in other control elements are two examples of features customers asked for but we couldn’t deliver on top of Win32.
As a UI platform, Windows Forms pushes Win32 very close to the limit. So then what would be left to deliver in a future version? Bug fixes? Definitely, but we will still do some of those. A few strategic new controls or new features in existing controls? Perhaps, but these are just refinements that will only yield small benefits to developers.
If the Avalon on XP announcement was never made, and we spent an entire product cycle working on a new version of Windows Forms, the type of features we'd work on would be more infrastructure-y. In Whidbey, we did ClickOnce and configuration. These features aren't specific to a UI platform and can be leveraged by all apps. A next version would bring more of this.
Well, it turns out that there are a set of folks on our team who will still do that type of work. Creating application infrastructure that will make common abstractions easier to integrate and manage. This work will apply to Windows Forms and Avalon and will be easily consumable by both UI models.
So UI library innovation for Windows Forms is finished. Does that make it dead?
Windows Forms obviously won't stop working anytime soon. The entire developer division is committed to compatibility. v1 and v1.1 apps will run on Whidbey and Whidbey apps will run on future versions of the framework. Also, versions of the framework are currently supported for something like 10 years after they are shipped. So if you write an app on top of Whidbey, you'll be able to call PSS about issues until around 2015.
Then the question becomes:
Is it worth investing in Windows Forms?
I still think the answer is yes. But let’s break the question down by timeframe.
Is it worth investing in Windows Forms today? Yes, I still think that VS.NET 2003 provides the most efficient way to create Win32 applications.
Is it worth investing in Windows Forms next year? YES!!! Whidbey rocks. The new controls, the new designer features and the bug fixes (transparency in an ImageList, Hallelujah!) all make for a very compelling feature set from a developer perspective.
Whidbey will make creating a professional looking Win32 app as easy as it was to create hello world with VB6. And Whidbey also provides a slick deployment mechanism with ClickOnce.
Is it worth investing in Windows Forms in 2 years? This is more of a judgment call. If you’re targeting only Windows XP and Longhorn, Avalon is the way to go. But Windows Forms is still the only way to write managed UI that will run on Win 2K and below. Couple this with the ability to detect whether Avalon is available and it becomes possible to write apps that will run on Windows 98 and still look great (via Avalon) on XP and Longhorn.
Will Windows Forms apps be able to integrate Longhorn controls in under 5 lines of code?
Yes
In my opinion, the Windows Forms to Avalon upgrade path is one of the smoothest there's ever been. Since both rely on managed code, there won't be any scary / hairy interop code. It will be as simple as adding a namespace (or a few J), instancing an Avalon element and adding it to a Windows Forms host control.
It all comes down to managed code. Once you've made the commitment to write your app on top of the CLR, switching between different managed APIs has a low overhead. This is true for both the mental model and the code itself. The same two lines of code that show a Windows Forms app today can be put anywhere in an Avalon app and will have the same functionality.
If I invest in a large Windows Forms app today will I have to rewrite it in 3 years for Avalon?
That's an interesting question. First off, lets look at the reasons people ever touch apps once they have been completed.
- To integrate new functionality
- To get a new look and feel
- To start their app from scratch
The plans for an Avalon design experience are far from finalized, but I can't imagine that we wouldn't enable the scenario of opening a Windows Forms Form in the designer, deleting a Windows Forms Button (or TextBox, or ListBox, or Panel, etc) and adding the Avalon equivalent. In my head I just imagine another tab on the toolbox with Avalon controls. I also see having an Avalon window as new project item as a possibility too.
The converse will also be true. Developers will be able to pluck any Windows Forms control off the toolbox and add it to an Avalon page.
No comments:
Post a Comment