Why Microsoft has made developers horrified about coding for Windows 8
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.
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.
A justified reaction
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.
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 were 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.
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 2D 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, and if you want high performance you can either use the low-level Direct2D from C++ directly—unpalatable—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 were going to be faced with little alternative but to embrace these inadequate technologies if they wanted 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.
API – Ars Technopaedia