Windows Forms to Developers: I’m not Dead Yet

In my recent blog “Spolsky 1: Scoble 0 – Stegman’s Video, while Great, doesn’t apply to the API war” the most surprising results were in the responses. While many did address the focus of the item (that of API changes), there were a number of responses directly relating to Windows Forms as a technology. Recently, Mike Harsh elaborated on this topic as well. Clearly there is interest in where Windows Forms fit into the greater scheme of things. I think this is worth of further discussion.

It’s possible Mike may be too conservative about the future of Windows forms. Curiously enough, the very issues that Joel brings up with regards to the API war actually work in favor of Windows Forms. You see, even though Windows Forms is a managed wrapper for User32, the key point is that it does wrap User32 – the old Win32 GDI API that every Windows developer in the world is familiar with.

So here comes Avalon – a new approach and new API. Do the features that Avalon promises truly justify the investment in learning this new API? It’s too soon to say. It will likely prove compelling to those developers who really need to take advantage of new UI features, just as the DirectX API is worth learning for those who need that capability, but that may prove to be a minority of Windows developers.

My point is this – you have a huge number of Windows programmers, who grew up and know User32, how it plays with VB6, MFC, ATL and now Windows Forms. Do you really think they’re all going to just jump to Avalon overnight? Over a year? Over 10 years? .NET has compelling advantages over COM, and the transition is proving very slow. There’s every reason to believe that the transition to Longhorn and Avalon (that in my mind are still classified in the category of vaporware) will be as slow or slower. If there is no compelling economic advantage, Windows Forms might be the dominant managed forms package for many years.

Unless, of course, Microsoft abandons Windows Forms, either on purpose, or by implication (say, by failing to make interop work as smoothly as promised on future OS’s).

It’s a tough problem. Technically, I do believe Windows Forms is better than VB6 or MFC. But it suffers from the .NET distribution issue. Even ClickOnce may not change that (a topic I’ll be writing about soon). Avalon will suffer the same runtime distribution issue, plus the additional problems of limited OS support and the need to learn a new API.

I was discussing this earlier today with Christian Gross, and he suggested I take a look at GTK# . I doubt it’s as cool as Avalon, maybe not even as cool as Windows Forms. But I must confess, the idea of a forms package that runs on Windows, OSX and Linux is intriguing. Something to look at… in my copious spare time.

7 Responses to “Windows Forms to Developers: I’m not Dead Yet”

  1. Mike Gale Says:

    I’d really like to see a few things like:

    APIs that really evolve and last a long time

    Still being able to use the old programming habits in the evolved new system.

    I don’t really believe in synchronicity but this post by Rockford Lohtka encapsulates some of what I’m thinking.

  2. Dan Says:

    Drazen Dotlic has an interesting comment at regarding user interface adoption of Avalon – also an important issue.

  3. annonymous Says:

    I thought Joel did not bother wether to use the old or the new API but rather to use web application instead (and leave the API decision to Macromedia and Adobe). Anyway, COM or not to COM, “ActiveX for the Prplxd” is still sitting on my DESKTOP and used twice a day (i don’t have enough thanks for this book)

  4. AndyB Says:

    Its less a problem with this new Windows Form technology being new, more that no-one quite knows what wil end up as the de-facto ‘forms standard’. MS isn;t giving out the right signals that Windows Forms is the one you should use to make all your apps with, so people are worrying whether if they start to use it, they’ll have to rewrite apps in a few years, and worse – learn yet another new technology (life is too short for us old folks who just want to make things work; and apparently the number of youngsters entering the industry is at an all time low)

    So, all in all, I think people will start looking at other established GUI technologies, or even stick to the old stuff until they’re sure they wont be lumbered with a load of apps that need expensive rewriting. Which is the reason the Raymond Chen camp should ‘win’ in MS, from a business point of view, as stability is essential – otherwise you might as well look at linux technologies, if you’re going to have to learn new stuff anyway.

  5. Daniel Moth Says:

    Blog link of the week 39

  6. Mike Harsh Says:

    I’ve added a post clarifying my wording about future versions. Check it out at:

  7. Jeff Atwood Says:

    The real question here is not “Should I develop in Windows Forms?” but “why should I even give a damn about Avalon?”

    I’m as tired of the hoary old pre-web Win32 GUI conventions as the next developer, but they’re extremely well developed and understood at this point. And I can certainly develop far richer apps with WinForms than I can in the browser. Dan, I’m not sure why you are down on Smart Client deployment, but we use it with great success at our Fortune 50 company. Smart Client (aka HREF exes) removes the only real barrier to WinForm development– deployment. Here’s how I deploy our smart client apps to our ~500 users: I copy files to a web server. It’s freaking great!

    To me, WinForms is a a serene island of power and stability. I certainly don’t miss dealing with ASP.NET craziness: endless postbacks, server-side processing of almost everything, and nonnensical event models where the event won’t fire if the target object doesn’t exist on the page (yet). Ugh.

    Avalon is the technology with questionable benefits (it’s prettier! it uses long overdue hardware acceleration and alphablending!) that is guilty until proven innocent. WinForms, on the other hand, is here to stay.

Leave a Reply

Comments are moderated - allow 24-48 hours for your comment to appear.