Most of us have experienced a moment of less-than-exciting Windows failure. Be it a monitor that comes up at the wrong resolution, or a control panel that hangs when you open it, Windows bugs can be frustrating—though admittedly, that’s true of every other desktop operating system.
But there is one major difference between fixing a problem in Mac OS X or Linux, and fixing a problem in Windows: On those other two operating systems, there’s probably only one very specific way to fix the problem. With Windows, there are many paths, from fixing DLLs to hacking the Registry.
From the developer perspective, Windows has long offered many—far too many—ways to develop applications. Too many API sets, too many application frameworks. This problem will be compounded by Windows 8, which includes WinRT, .NET, C++ and HTML5 application support—and more besides, such as Silverlight or even native Win32. At the beginning of the project, the developer must choose a direction. Which is right?
While coding, programmers may run into severe limitations with some of those choices. Developers who choose WinRT will be able to build Metro-style native Windows 8 apps, but they’ll be restricted from fully touching the hardware, and even from touching all of the Windows features, because WinRT is limited by design. Build an HTML5 app for Windows 8 and you’ll be ready for moving to Windows Phone, but you’ll miss out on the native Windows look and feel, and again be shut out from some core functionalities.
Choose .NET or C++, and you’re basically negating all the advantages of Windows 8’s new user experience, but you’ll maintain compatibility with Windows 7 and earlier systems. Of course, using those two technologies also limits your access to the new UI controls offered in Metro, like the swipe bar, the app bar and the semantic zoom. You can’t win.
Anyone who’s ever troubleshot Windows knows that just about every administrative and maintenance task can be done in a half-dozen ways, and only one of those ways is the “right” way. Now it seems developers are still saddled with this “100 ways to do it” thinking. Microsoft: Pick fewer ways to build applications, deprecate the other methods, and make sure that one-way-to-rule-them-all is super optimized, super intuitive, super compatible and never complains that “you’re doing it wrong.” Show leadership by picking a direction—and sticking with it.
HTML5’s next-generation browser wars
The standards are winning. When it comes to cross-platform rich Internet applications, HTML5 is not so slowly emerging as the platform of choice. Sure, Silverlight has many synergies for .NET developers, and Flash has a large installed base of users and developers. However, it is clear to us, and presumably to most of the industry, that the richness of HTML5 will ultimately prevail for Web-based applications, and perhaps even for many offline apps as well.
We are worried about two factors with the rush to HTML5: On the short term, there’s maturity. Long term, compatibility.
Never forget that HTML5 remains a work in progress. You’d never know that from listening to the platform vendors. Apple says, for example, “Every new Apple mobile device and every new Mac—along with the latest version of Apple’s Safari Web browser—supports Web standards, including HTML5, CSS3 and JavaScript. These Web standards are open, reliable, highly secure and efficient.”
HTML5 is incomplete and is constantly changing. How will today’s HTML5 applications work in the future? We can hope for the best, but can’t count on it. By contrast, Silverlight and Flash are both mature and ready for business-critical applications.
And that brings us to compatibility and standards compliance. With proprietary platforms like Flash and Silverlight, you have a single company that develops and maintains the language, development tools and runtime platforms. You can expect them to ensure compatibility between all three components, and if something doesn’t work, you know whom to blame.
With HTML—both now and in the future—developers will be dealing with specific implementations of a huge and tremendously complex set of specifications. Perhaps we are paranoid in being concerned about compliance with those specifications, but we have unhappy memories of browser challenges with HTML4 and earlier.
Forget Acid3. HTML5 is going to be a compliance nightmare that will make challenges like testing SVG and DOM look like child’s play.
What’s worse is that at least with HTML4 and earlier, desktop and mobile users could (for the most part) have their choice of browsers, and could try different options when necessary. If a particular Web page or Web application didn’t work in Firefox, you could try Internet Explorer; if Safari gave you issues, there’s always Opera or Chrome. Certainly that wasn’t always a viable choice; some platforms lock users into specific browsers; some enterprise IT departments restrict browsers as well; and some applications include built-in HTML renderers like WebKit or Gecko that can’t be swapped out.
By contrast, HTML5 is baked into the operating system itself. With non-open-source desktop platforms, like Mac OS X or Windows, end users will have no way to address a compatibility issue with HTML5; it will have to be fixed with a service update to the operating system. Presumably, that will be true with Android, iOS and Windows Phone as well.
Bottom line: If you want to ride the leading edge of the rich Internet experience, go ahead and surf HTML5. But if you want reliability and compliance, the proprietary RIA platforms are still the best choice.
