Hasta La Gadget!

Developing for the new Windows 8 platform won't be anything like developers' past experiences, according to Microsoft. (Photo courtesy Ars Technica)

By Peter Bright, Ars Technica

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 troubles many developers is the way that Microsoft has said these APIs will be used. Three minutes and 45 seconds into a demo video, Microsoft Vice President Julie Larson-Green, in charge of the Windows Experience, briefly describes a new immersive 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 and 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 in Windows development and countless hours spent learning Microsoft’s latest-and-greatest technology. 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 already suspected. Developers aren’t willing to assume that the company is going to do right by them, because the messages from the company have 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. There’s been too much infighting, 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 be, 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.