Tech

Wednesday 15 June 2011

Why Microsoft has made developers horrified about coding for Windows 8


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.
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 APIsfor 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.

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 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.
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 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.

Inexplicable silence

Given the justified fear this has struck within the developer community, one might have expected Microsoft to do something to put minds at ease. After all, if the company isn't in fact going to trash the knowledge and experience of every current Windows developer, it would probably be a good idea to get that message out.
Instead, the company has decided that the appropriate response is to say that D9 wasn't a developer-focused event, and that the company will talk about the development platform in September at its BUILD event. And beyond that? Nothing. Not even so much as a "don't worry, there will definitely be a way to use .NET and native code to write immersive applications, we're not going to render your experience irrelevant, you're going to be able to use the tools you're familiar with." Nothing.

Abandon ship

This is a dangerous strategy. Windows is still going to be king of the corporate desktop for a long time to come, so developers of business-oriented line-of-business applications have little choice but to like what Microsoft is making them use, so regardless of their frustrations there's little real risk in that market. But the same isn't true of developers in targeting more consumer-focused tablet and smartphone markets. Redmond is behind in both of those; Windows Phone is less than a year old and is off to a slow start, and the company won't have a credible tablet platform at all until Windows 8. To succeed in both markets, the company needs shiny new immersive applications. That's not a sufficient condition—having applications isn't enough to assure success, you need users for that—but it's a necessary one. If Windows 8 tablets have no tablet applications, they'll never be able to challenge the iPad.
Windows Phone 7 Marketplace growth since its release
One of the big things the company still that has in its favor is its development tools and large developer community. Windows Phone clearly demonstrates the value of this community: the platform is punching well above its weight when it comes to the number of applications available. Already it has more than 20,000 applications, surpassing webOS's store, and arguably BlackBerry's App World. The fact that Windows Phone uses Silverlight for its development has plainly been instrumental in this growth. It's so easy, familiar, and perhaps even fun to develop for the platform that people are doing so in spite of the low user numbers.
Those developing for the phone might well expect to be able to directly apply their phone expertise to Windows 8. Tablets powered by both Apple's and Google's operating systems can run software built for their telephonic siblings, and an equivalent facility for Windows 8 tablets is surely a no-brainer. Even those who haven't yet taken the phone plunge are sure to be interested in using their existing Windows development skills to develop tablet applications.
Yet these developers now feel they're being told that if they want to target the tablet, they've got to throw away all that they know. The very developers that the company should be courting are being given good reason to doubt the future of the platform. And they're genuinely angry and worried by this. The prospect of being stuck with HTML5 and JavaScript for their development is encouraging them to jump ship.

The rebirth of the application

The great irony in all this is that for the longest time, Microsoft treated Web applications as an existential threat. If the Web itself became the platform then people would no longer need Windows applications, and hence they would no longer need Windows itself. The aggressive moves to crush Netscape and win the browser war was a direct response to this perception; if the Web were to become the platform, then at the very least Microsoft wanted it to be a Microsoft-controlled Web, accessed through Microsoft products.
A decade after Microsoft's victory in the browser war, far from seeing the replacement of rich client applications by Web applications, we're seeing explosive growth in the client application field. Rich applications—many of them front-ends to cloud-hosted Web applications—are booming, thanks to the smartphone and tablet markets. The enormous success of Apple's App Store and the Android Market has bucked the trend towards Web applications, and reinvigorated the development of rich client applications, as developers are using them to provide better, more capable, user experiences than they can achieve with the Web alone.
While this trend may not last forever—the Financial Times' Web application, designed as a deliberate end-run around Apple's App Store policies shows that there's still a lot of interest in the Web app model—it's still the case that real applications are hotter and more important today than anyone would have predicted five years ago.
Smartphones and tablets have made applications important again, and Microsoft, more than any other company in the world, should be able to capitalize on this. Microsoft has the best development tools and a huge wealth of third-party developers who are just waiting for the chance to bring their skills to bear on the company's new tablet platform—just as long as it will let them.

Mad, but not stupid

Microsoft remains silent. It's apparently happy for developers to think that HTML5 and JavaScript are the only option for immersive Windows 8 applications, regardless of the distress and damage this is causing. And the longer the company remains silent, the more convinced people will be that the reason that Microsoft isn't debunking the claims is because there's nothing to debunk: HTML5 and JavaScript really could be the whole story when it comes to immersive applications. If it isn't, the decision to say nothing is incomprehensible. Saying nothing can only hurt. Developers are losing faith in the platform today; waiting to September to set them straight is madness.
But Microsoft isn't stupid. Its messaging and PR around this issue may be crazy, and the way developers have responded is rational, but the company isn't going to alienate its enormous base of developers and force them to trash everything they've ever learned. Windows 8 will offer a new API, and you're not going to have to write webpages to use it.
The company may not have made any official statement about it, but leaks are coming out, and a picture is starting to emerge. The details aren't clear yet, but next time we'll take a look at the pieces of the puzzle we have, and we'll learn why Windows 8 won't be a HTML-driven horror after all.

No comments:

Post a Comment