Why Microsoft Has Made Developers Horrified of Coding for Windows 8

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.

Hopes Dashed

But then Internet Explorer 9 happened. Microsoft jumped on the HTML5 bandwagon, and that’s when things all got rather muddy. Prior to Internet Explorer 9, Silverlight had been the company’s preferred solution for developing rich cross-platform applications. The lack of broad platform support meant that Silverlight could never quite rival Flash on this front, but it was there, and it worked well on those platforms that were supported. With Internet Explorer 9, however, Silverlight took a back seat. HTML5 became the way forward. If Silverlight was to be used at all, it should only be used for those things that HTML5 couldn’t do very well, such as streaming video. For anything else, the message was that developers should use HTML5.

Microsoft did have a point. If you’re really wanting to target people on any platform, HTML5 is the way to go. For Web-facing applications that don’t have any special needs such as DRM video, HTML5 is the long-term bet. But third-party developers were deeply unhappy when this repositioning was made explicit, and they had a point too. For a developer writing an internal-use line-of-business application, one for whom depending on a browser plug-in is not a problem, Silverlight had, and still has, a lot of points in its favor.

HTML5 remains true to its text mark-up heritage. Its structure and semantics are still geared towards creating structured text documents, not application user interfaces. Where Silverlight programs can deal with buttons, icons, list boxes, tree views and other interface controls, HTML5 applications must generally deal with boxes of text, with no higher-level concepts to work with. There are JavaScript libraries that attempt to bridge this gap, but they lack the capabilities and control that Silverlight offers. Ultimately, if one were to design a framework for creating user interfaces, it would look a lot more like Silverlight than it does HTML5.

Another weak area for HTML5 is tooling. Design and development tools that work with HTML5 are not as developed or as robust as those that exist for Silverlight, making HTML5 development more complicated, especially as application complexity increases. Thus far, though the company has continued to promote it as the first choice for browser-deployed applications, Microsoft has done little to address these issues with HTML5.

Redmond has, however, done something with HTML5 that it has never bothered to do for either Silverlight or WPF, and that’s make it fast. Internet Explorer 9 builds on top of an API called Direct2D. This is a 2-D graphics library that uses Direct3D 10 for acceleration. The Direct2D API is even lower-level than HTML5; while HTML5 pages are basically built up of text boxes, these boxes do have some “intelligence” of their own; they have layout rules, borders, backgrounds, and more. Direct2D in contrast can handle little more than curved lines — or groups of curved lines — with every aspect of layout left to the developer. And unlike the inefficient way in which WPF uses Direct3D, Internet Explorer 9 and Direct2D have been optimized and are far more efficient.

With Internet Explorer 9, Microsoft was therefore telling its developer community two things: HTML5 is the preferred technology, regardless of its suitability or desirability. If you want high performance you can either use the low-level Direct2D from C++ directly — an unpalatable option — or the mid-level HTML5. If you want a high-level, purpose-built API with high performance — a version of WPF built on top of Direct2D, for example — it isn’t going to happen.

The Windows 8 comment thus seems to be the culmination of Microsoft’s policy of the last few years. HTML5 was already the blessed development platform in spite of its many failings, and with Windows 8 developers are going to be faced with little alternative but to embrace these inadequate technologies if they want to produce new-style immersive applications. As crazy and destructive as this policy appears, it has the feeling of consistency. Internet Explorer 9 and the downplaying of Silverlight were the first step down this path; immersive applications requiring use of HTML5 are the next.