Is Windows Forms Dead?
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.
All of this will make the first two goals of upgrading an app fairly straightforward to implement. The third reason, creating an Avalon app from scratch will require more design work and more code, but the mental model of working with managed code will make this transition more smooth than say VB6 to VB.NET or MFC to Windows Forms.
Comments
Anonymous
September 20, 2004
I am not very familiar with Avalon details but have seen some presentations about it. Does development in Avalon imply working with XAML (using both XML and codebehind file)? Or does Avalon provide an API (like WinForms) that I could just use (all code) without messing with XML tags? I ask this because as a developer I find myself more comfortable with "{ }" than the overused "< >". It's just a personal preference, but I see the relevance of XAML.Anonymous
September 20, 2004
Kris, yes, Avalon is the UI technology that XAML describes. Avalon has both a programattic interface and a delcarative one. I comoletely agree with you about being more comfortable writing code than markup. I guess it's just based on what you are used to, but it is cool that Avalon supports both models.Anonymous
September 20, 2004
"it is cool that Avalon supports both models". Well, it depends, doesn't it? I guess only tool support for the declarative model will be available. If this is the case, I don't see many people going down a path that is not supported by the tool ('VS.NET' that is).Anonymous
September 20, 2004
I agree that it would be beneficial to have tool support for both the code and markup models of creating Avalon UI. I wouldn't make any assumptions about the level of tool support yet. It is still too far away.Anonymous
September 20, 2004
Mike,
I think comparing WinForms to Avalon is the wrong perspective. WinForms has never been nearly popular as ASP.NET, for reasons that have nothing to do with Avalon:
1) WinForms apps require a 20MB download of the .NET runtime, which most people still don't have. For obvious reasons, this is a HUGE factor for developers. Why didn't Microsoft include the framework with XP SP2?
2) GDI+ is dog slow, so that custom controls are a pain to optimize. Worse, last time I checked, there's no plan to accelerate GDI+. Doesn't this invite doubts about Microsoft's commitment to WinForms?
If you can solve the above two problems, WinForms development will take off like a rocket.Anonymous
September 20, 2004
A quote from a post over on simplegeek
http://www.simplegeek.com/permalink.aspx/a6be0f9f-2bd5-4a5f-9e39-d2ccc7cc1b09
Joe Says in point 2 of 4 regarding Avalon on XP:
Inability to really tweak User32. In Longhorn builds we had the ability to do "child window redirection". This is a Win32 interop solution where child hWnds get redirected by the system to a bitmap that the Avalon compositor then hosts. This allowed Win32 content to alpha blend and rotate just like any Avalon content. Since we won't be able to change system binaries on older systems, we won't be able to do this redirection on XP and W2k3. We'll have to find a compromise solution to hosting legacy content. You probably won't be able to treat it like regular Avalon content. Eventually we want to be able to support these advanced legacy hosting solutions, but it probably won't work on XP and W2k3.
This makes the WinForms/Avalon integration you describe sound a bit unrealistic. Comments?Anonymous
September 20, 2004
Tom, it means that the interop on XP won't be quite as good as it will be on Longhorn. That translates to Windows Forms controls, on XP only, being limited to opaque rectangles in an Avalon app. You won't be able to blend the WF control with the background of it's Avalon parent. You won't be able to have a Windows Forms control participate in scaling and rotating transforms like Avalon elements.
On the other hand, anything your Windows Forms control could do in Windows Forms will still be possible, there won't be any loss of Win32 functionality.
And of course, these limitations won't exist when running on Longhorn.Anonymous
September 21, 2004
GDI+ is only dog slow if you don't have an optimized graphics system, like VG.net. It can be quite fast when used properly.
The unanaswered question about avalon on XP: how can it be compatible with windows forms if it uses DirectX? These applications do not mix well with windows forms -- they do not interoperate at all. So if it is not based on DirectX, then it will be another GDI+ type of software rendering, only this time much fatter and slower, because of all the large data structures and overengineering.
Don't tell people to focus on Avalon for XP until they have a stable enough release to do performance testing. The Avalon minimum hardware requirements are very steep.Anonymous
September 21, 2004
"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."
You may be giving up too quickly, Mike. See my detailed response at http://www.danappleman.com/index.php?p=18Anonymous
September 22, 2004
The debate goes on...Anonymous
September 22, 2004
In my previous entry—The API Skirmish—I tried to defend the viability of WindowsForms as a development platform. Had I known about Mike Harsh’s short essay on the subject before writing that entry, I would have saved myself a lot of...Anonymous
September 22, 2004
Mike, is that really true though? I do not see XAML as truely Avalon specific even though most of the samples currently shown are for Avalon. But in general, isn't XAML a declarative approach to instantiating objects and setting properties? One could use it to instantiate business objects, no?
Also, when creating Longhorn projects, one uses XAML to create things such as applications and other things.
I'd love to hear your thoughts on this...Anonymous
September 22, 2004
I think the idea that you can't really add much value to WinForms anymore is mistaken. True, you might hit many, many problems when you try to introduce "big things". But when you say that introducing more controls and tweaking the exisiting ones doesn't bring much benefit ("Perhaps, but these are just refinements that will only yield small benefits to developers") I think you are missing the real day problems of developers big time.
To me a UI framework is really valuable when ALL the little small details are taken care of. Are all controls data bindable? Is every little detail covered and tested in praxis? No first generation or second generation framework I worked so far with had all the little things worked out, and way too often these little details were the real productivity bummers for my projects. Delphi's VCL is very mature today, after how many releases? Small, incremental improvements, no break through things. Same for MFC, as far as I can say.
I can understand that you guys want to rush on the next big thing, but the true value of any framework comes once it has matured, and that just isn't the case with Whidbey, as far as I can tell... No surprise, because it probably simply takes more release cycles to reach that stage. If you stop that development now with WinForms and start over with Avalon, there won't be anything mature for many more years from Microsoft. Big mistake, I belive.Anonymous
September 22, 2004
A colleague of mine recently pointed me to this entry. As a software developer, this whole issue is giving me serious reserverations about Microsoft's UI strategy (and I use that term loosely).
Those of us that have huge C++ code bases have no upgrade path. This is a huge gap. I'm sure your internal customers have the same problem. What story are you giving the Excel team? My guess is they are doing what the rest of us are doing, and ignoring all this non-sense until something comes out of it.
To be honest, if I was to start a large desktop application today (not very likely), I would probably go for QT. At least Trolltech has a vested interested in supporting their framework over the long term.Anonymous
September 22, 2004
Interesting article. This page has a few glitches when viewed from Mozilla browsers.Anonymous
October 05, 2004
The debate goes on...Anonymous
November 27, 2004
When do I use which?Anonymous
January 25, 2008
PingBack from http://softwareinformation.247blogging.info/mike-harshs-blog-is-windows-forms-dead/Anonymous
January 21, 2009
PingBack from http://www.keyongtech.com/568335-is-whidbey-already-deadAnonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=mike-harsh-s-blog-is-windows-forms-deadAnonymous
May 31, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=1042Anonymous
June 15, 2009
PingBack from http://debtsolutionsnow.info/story.php?id=13233Anonymous
June 15, 2009
PingBack from http://workfromhomecareer.info/story.php?id=20379Anonymous
June 17, 2009
PingBack from http://patiosetsite.info/story.php?id=600