Windows 8 Will be Here Tomorrow; but Should Silverlight be Gone Today?
- by andrewbrust
The software industry lives within an interesting paradox. IT in the enterprise moves slowly and cautiously, upgrading only when safe and necessary. IT interests intentionally live in the past. On the other hand, developers, and Independent Software Vendors (ISVs) not only want to use the latest and greatest technologies, but this constituency prides itself on gauging tech’s future, and basing its present-day strategy upon it. Normally, we as an industry manage this paradox with a shrug of the shoulder and musings along the lines of “it takes all kinds.” Different subcultures have different tendencies. So be it. Microsoft, with its Windows operating system (OS), can’t take such a laissez-faire view of the world though. Redmond relies on IT to deploy Windows and (at the very least) influence its procurement, but it also relies on developers to build software for Windows, especially software that has a dependency on features in new versions of the OS. It must indulge and nourish developers’ fetish for an early birthing of the next generation of software, even as it acknowledges the IT reality that the next wave will arrive on-schedule in Redmond and will travel very slowly to end users. With the move to Windows 8, and the corresponding shift in application development models, this paradox is certainly in place. On the one hand, the next version of Windows is widely expected sometime in 2012, and its full-scale deployment will likely push into 2014 or even later. Meanwhile, there’s a technology that runs on today’s Windows 7, will continue to run in the desktop mode of Windows 8 (the next version’s codename), and provides absolutely the best architectural bridge to the Windows 8 Metro-style application development stack. That technology is Silverlight. And given what we now know about Windows 8, one might think, as I do, that Microsoft ecosystem developers should be flocking to it. But because developers are trying to get a jump on the future, and since many of them believe the impending v5.0 release of Silverlight will be the technology’s last, not everyone is flocking to it; in fact some are fleeing from it. Is this sensible? Is it not unprecedented? What options does it lead to? What’s the right way to think about the situation? Is v5.0 really the last major version of the technology called Silverlight? We don’t know. But Scott Guthrie, the “father” and champion of the technology, left the Developer Division of Microsoft months ago to work on the Windows Azure team, and he took his people with him. John Papa, who was a very influential Redmond-based evangelist for Silverlight (and is a Visual Studio Magazine author), left Microsoft completely. About a year ago, when initial suspicion of Silverlight’s demise reached significant magnitude, Papa interviewed Guthrie on video and their discussion served to dispel developers’ fears; but now they’ve moved on. So read into that what you will and let’s suppose, for the sake of argument, speculation that Silverlight’s days of major revision and iteration are over now is correct. Let’s assume the shine and glimmer has dimmed. Let’s assume that any Silverlight application written today, and that therefore any investment of financial and human resources made in Silverlight development today, is destined for rework and extra investment in a few years, if the application’s platform needs to stay current. Is this really so different from any technology investment we make? Every framework, language, runtime and operating system is subject to change, to improvement, to flux and, yes, to obsolescence. What differs from project to project, is how near-term that obsolescence is and how disruptive the change will be. The shift from .NET 1.1. to 2.0 was incremental. Some of the further changes were too. But the switch from Windows Forms to WPF was major, and the change from ASP.NET Web Services (asmx) to Windows Communication Foundation (WCF) was downright fundamental. Meanwhile, the transition to the .NET development model for Windows 8 Metro-style applications is actually quite gentle. The finer points of this subject are covered nicely in Magenic’s excellent white paper “Assessing the Windows 8 Development Platform.” As the authors of that paper (including Rocky Lhotka) point out, Silverlight code won’t just “port” to Windows 8. And, no, Silverlight user interfaces won’t either; Metro always supports XAML, but that relationship is not commutative. But the concepts, the syntax, the architecture and developers’ skills map from Silverlight to Windows 8 Metro and the Windows Runtime (WinRT) very nicely. That’s not a coincidence. It’s not an accident. This is a protected transition. It’s not a slap in the face. There are few things that are unnerving about this transition, which make it seem markedly different from others: The assumed end of the road for Silverlight is something many think they can see. Instead of being ignorant of the technology’s expiration date, we believe we know it. If ignorance is bliss, it would seem our situation lacks it. The new technology involving WinRT and Metro involves a name change from Silverlight. .NET, which underlies both Silverlight and the XAML approach to WinRT development, has just about reached 10 years of age. That’s equivalent to 80 in human years, or so many fear. My take is that the combination of these three factors has contributed to what for many is a psychologically compelling case that Silverlight should be abandoned today and HTML 5 (the agnostic kind, not the Windows RT variety) should be embraced in its stead. I understand the logic behind that. I appreciate the preemptive, proactive, vigilant conscientiousness involved in its calculus. But for a great many scenarios, I don’t agree with it. HTML 5 clients, no matter how impressive their interactivity and the emulation of native application interfaces they present may be, are still second-class clients. They are getting better, especially when hardware acceleration and fast processors are involved. But they still lag. They still feel like they’re emulating something, like they’re prototypes, like they’re not comfortable in their own skins. They are based on compromise, and they feel compromised too. HTML 5/JavaScript development tools are getting better, and will get better still, but they are not as productive as tools for other environments, like Flash, like Silverlight or even more primitive tooling for iOS or Android. HTML’s roots as a document markup language, rather than an application interface, create a disconnect that impedes productivity. I do not necessarily think that problem is insurmountable, but it’s here today. If you’re building line-of-business applications, you need a first-class client and you need productivity. Lack of productivity increases your costs and worsens your backlog. A second class client will erode user satisfaction, which is never good. Worse yet, this erosion will be inconspicuous, rather than easily identified and diagnosed, because the inferiority of an HTML 5 client over a native one is hard to identify and, notably, doing so at this juncture in the industry is unpopular. Why would you fault a technology that everyone believes is revolutionary? Instead, user disenchantment will remain latent and yet will add to the malaise caused by slower development. If you’re an ISV and you’re coveting the reach of running multi-platform, it’s a different story. You’ve likely wanted to move to HTML 5 already, and the uncertainty around Silverlight may be the only remaining momentum or pretext you need to make the shift. You’re deploying many more copies of your application than a line-of-business developer is anyway; this makes the economic hit from lower productivity less impactful, and the wider potential installed base might even make it profitable. But no matter who you are, it’s important to take stock of the situation and do it accurately. Continued, but merely incremental changes in a development model lead to conservatism and general lack of innovation in the underlying platform. Periods of stability and equilibrium are necessary, but permanence in that equilibrium leads to loss of platform relevance, market share and utility. Arguably, that’s already happened to Windows. The change Windows 8 brings is necessary and overdue. The marked changes in using .NET if we’re to build applications for the new OS are inevitable. We will ultimately benefit from the change, and what we can reasonably hope for in the interim is a migration path for our code and skills that is navigable, logical and conceptually comfortable. That path takes us to a place called WinRT, rather than a place called Silverlight. But considering everything that is changing for the good, the number of disruptive changes is impressively minimal. The name may be changing, and there may even be some significance to that in terms of Microsoft’s internal management of products and technologies. But as the consumer, you should care about the ingredients, not the name. Turkish coffee and Greek coffee are much the same. Although you’ll find plenty of interested parties who will find the names significant, drinkers of the beverage should enjoy either one. It’s all coffee, it’s all sweet, and you can tell your fortune from the grounds that are left at the end. Back on the software side, it’s all XAML, and C# or VB .NET, and you can make your fortune from the product that comes out at the end. Coffee drinkers wouldn’t switch to tea. Why should XAML developers switch to HTML?
