Why Microsoft has made developers horrified about coding for Windows 8

As a Windows developer (Silverlight, WPF), I am a little worried as well. [Link]

When Microsoft gave the first public demonstration of Windows 8 a week ago, the reaction from most circles was positive. The new Windows 8 user interface looks clean, attractive, and thoughtful, and in a first for a Microsoft desktop operating system, it's finger friendly. But one aspect of the demonstration has the legions of Windows developers deeply concerned, and with good reason: they were told that all their experience, all their knowledge, and every program they have written in the past would be useless on Windows 8.

Key to the new Windows 8 look and feel, and instrumental to Microsoft's bid to make Windows a viable tablet operating system, are new-style full-screen "immersive" applications. Windows 8 will include new APIs for developing these applications, and here is where the problem lies. Having new APIs isn't itself a concern—there's simply never been anything like this on Windows before, so obviously the existing Windows APIs won't do the job—but what has many troubled is the way that Microsoft has said these APIs will be used. Three minutes and forty five seconds into this video, Microsoft Vice President Julie Larson-Green, in charge of the Windows Experience, briefly describes a new immersive application—a weather application—and says, specifically, that the application uses "our new developer platform, which is, uhh, it's based on HTML5 and JavaScript."

Cue much wailing and gnashing of teeth.

Windows developers have invested a lot of time, effort, and money into the platform. Over the years, they've learned Win32, COM, MFC, ATL, Visual Basic 6, .NET, WinForms, Silverlight, WPF. All of these technologies were, at one time or another, instrumental in creating desktop applications on Windows. With the exception of Visual Basic 6, all of them are still more or less supported on Windows today, and none of them can do it all; all except Visual Basic 6 and WinForms have a role to play in modern Windows development.

Hearing that Windows 8 would use HTML5 and JavaScript for its new immersive applications was, therefore, more than a little disturbing to Windows developers. Such a switch means discarding two decades of knowledge and expertise of Windows development—and countless hours spent learning Microsoft's latest-and-greatest technology—and perhaps just as importantly, it means discarding rich, capable frameworks and the powerful, enormously popular Visual Studio development environment, in favor of a far more primitive, rudimentary system with substantially inferior tools.

A justified reaction

The idea of Microsoft discarding all of that expertise seems crazy, and one might think that the developer response is an overreaction—but it's seen as confirmation of the direction Microsoft already appears to be heading down: moving HTML5 to the foreground, in spite of its inferiority to other technology. The Windows 8 comment made by Larson-Green was shocking, yes, but seemed to be confirmation of what developers were already suspicious of. Developers aren't willing to assume that the company is going to do right by them, because the messaging from the company has given them every reason to believe that the Larson-Green really meant what she said; if you want to use the new development platform, you're going to have to use HTML5 and JavaScript.

The company has never exactly been good at picking a direction for its development strategy and sticking with it. Too much in-fighting, too many leaps aboard new technology bandwagons, and too much software that fails to adopt new paradigms. But until about a year and a half ago, it looked like things were beginning to settle down, with the combination of .NET, Windows Presentation Foundation (WPF), and WPF's Flash-like sibling, Silverlight. WPF and .NET provide a flexible, high-level, and structured approach for writing GUI applications, and Silverlight is a cut-down version of WPF that can be used as a browser plugin on both Windows and Mac OS X.

Neither of these technologies was perfect—WPF has never been as fast as it should have, and Silverlight is not as cross-platform as it ought to be—but the set of products did at least represent some kind of a coherent vision for software development. WPF and .NET for big applications, Silverlight for portable ones.