When I came back from vacation all hell had broken loose. You see, a few days before I came back, Microsoft decided that WinFX, or at least the bits that remained after the latest round of Longhorn cuts, would also be supported on downlevel platforms. To a guy deeply entrenched in the development of Windows Forms, this is fairly impactful news as a key part of WinFX is Avalon.
Not that the news wasn’t welcome. I’d been lobbying the powers that be for months that this is the right thing for customers. People buy Windows because of the apps they can run on Windows. Developers write apps for Windows because it is the most pervasive platform so they get the broadest reach. Producing a brand-new API and only exposing it on a version of Windows that no one has does not encourage developers to spend valuable time writing apps for it, especially if they can write to an existing API and support both the old and new operating systems.
It’s interesting to think that someone from the Windows Forms team would want Avalon to come down level. That muddies the waters quite a bit, doesn’t it? Mike Harsh’s post underscores what a lot of us on the Windows Forms team have been thinking: are we working on dead technology? Or more to the point, why would people want to code against Avalon instead of Windows Forms?
The answer is different depending on which kind of developer you’re talking to. If you’re talking to an application developer whose primary job is to combine existing controls from the toolbox into an application, then that developer probably doesn’t give much of a hoo-ha whether she uses Avalon or Windows Forms provided they have similar development experiences. The differences are purely technological, hidden away under the covers. Those developers will continue to happily use Windows Forms until cool controls cease to exist for it some time in the far far future.
If, on the other hand, you’re a control vendor creating controls to put on that toolbox you care a great deal. You want an API that doesn’t come between you and control nirvana. Here is where Windows Forms starts to lose a bit of its luster. Windows Forms is built on Win32. For many of us, that’s a good thing. We grew up with the Petzold book and Win32 is comfortable to us. But even those of us who work deep in message routing and GDI every day have trouble implementing controls. Why? Because Win32 is showing its age. The user interfaces elements found on modern applications couldn’t have even been imagined when Win32 was first designed. Do you know how many people in the Office team work on creating those coveted Office-style toolbars? Lots. More than some software companies have on their entire development staff.
Windows Forms gives Win32 a lot of enhanced abilities. Our own office style toolbars – ToolStrips – were written by only two (very capable and obsessive) developers. Those developers were able to leverage richer layouts, GDI+ rendering, and managed code to do what would have otherwise required an army. The Office team was not impressed. But those two developers will tell you that it was still quite a lot of work, tweaking pixels here and there, inventing a lightweight element model for the items in a toolstrip, allowing large controls to be composited inside those lighter elements, even implementing a proper pop-up window so focus stays where you want it and your application title bar stays the right color was a challenge.
That is where Avalon excels: it is a technology that takes more of the complexity out of doing complex tasks. It’s not revolutionary, its evolutionary. And, it’s sorely needed. It’s needed by control developers everywhere so they can create controls with great usability without hiring an army of Win32 experts. It’s needed by end users because they deserve to have great usability in all their applications, not just the ones that Microsoft threw a bazillion dollars at.
It’s important to cut through the marketing hype and recognize Avalon for what it is: a modern day compositing and rendering engine. Sure, it can do dancing hippos. So can the web, but thankfully we moved past that. It’s also important to realize that from an application developer’s perspective, there is little difference between Avalon and Windows Forms. For years there will be interesting controls built from both technologies. I wouldn’t be surprised if there were even controls that were simultaneously built from both technologies, say selling as a Windows Forms control but rendering internally using Avalon. It will be crucial that Microsoft allow developers to mix and match between these two technologies for as long as it makes sense. Personally, I’m looking forward to it.