Geeks With Blogs

BrustBlog Pontifications on Microsoft and the Tech Industry

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?

Posted on Wednesday, November 23, 2011 3:51 PM | Back to top

Comments on this post: Windows 8 Will be Here Tomorrow; but Should Silverlight be Gone Today?

# re: Windows 8 Will be Here Tomorrow; but Should Silverlight be Gone Today?
Requesting Gravatar...
The thing we have to let go of is "write once run everywhere". Let that go and you will be fine. You will make HTML pages where they make sense and you will make an IOS app where you need one, and Android app where you need one, and a Windows Forms/WPF/Silverlight app.
Left by Michael Washington on Nov 23, 2011 4:31 PM

# re: Windows 8 Will be Here Tomorrow; but Should Silverlight be Gone Today?
Requesting Gravatar...
The assumption that Silverlight developers should just move to Windows 8 XAML and Metro is as ridiculous as all those shills a year ago telling us Silverlight wasn't dead, when internally everybody who'd been working on Silverlight was "rushing into HTML5".

The signs are self-evident. The future is HTML5 not XAML and the big plus is it opens up other platforms instead of locking developers into the usual Microsoft proprietary "drag and drop demoware of a product we'll likely abandon as soon as we think we can".

The signs are very evident. Blend in its initial release is HTML only. Most of the demos are Javascript and HTML and CSS. Former Silverlight employees and MVPs are all rushing to produce jQuery and Javascript courses for Pluralsight and others.

Smell the coffee. XAML was an expensive experiment that Sinofsky and his crew are paying lip service to in the short term because of the huge public backlash last year when rumours that Silverlight was going to be killed first surfaced.

When the shills who keep telling us "Silverlight isn't really dead just think of Windows 8 as Silverlight v6" are busy doing the opposite of what they keep preaching the writing is on the wall.

Adobe have dropped Flash for Mobile for a reason and they too are moving to HTML5. Developers shouldn't be wasting any more time on Microsoft proprietary stacks even if the learning curve is slightly shorter in the near term. Longer term the future is very clear and Silverlight developers should follow what the evengelists are DOING rather than SAYING - get up to speed on the alternatives to XAML! Arguments about the technical superiority of one over the other, or the pain levels are irrelevant at this point.
Left by Ian Smith on Nov 24, 2011 3:51 AM

# re: Windows 8 Will be Here Tomorrow; but Should Silverlight be Gone Today?
Requesting Gravatar...
"Why should XAML developers switch to HTML?" When you need to support multiple platforms, or need to build browser centric applications. There are still many use cases where this is prefereable to so-called "smart clients", and the idea that a web client is always a second class citizen is not held up by adoption of the web clients for enterprise software.

Microsoft's muddy guidance with respect to Silverlight and HTML 5 have not done the development community any favors or helped Microsoft's otherwise good reputation with them. The only reason I'm devoting any time and attention to Silverlight is purely due to Windows Phone 7.
Left by Richard Brantley on Nov 28, 2011 10:01 AM

# re: Windows 8 Will be Here Tomorrow; but Should Silverlight be Gone Today?
Requesting Gravatar...
The fact is developers are flocking away from Silverlight because not even Microsoft is commiting to it. They have been choking developers and ISVs with so much vapor-infrastructure-ware that they opened themselves for other companies with a more focused and clear strategy (namely, Apple and Google) to take their place in the minds and hearts of developers; so much that all Redmond can rely on is on its established user base to continue to make money. They have become I-R-R-E-L-E-V-A-N-T. So much that they have not been able to kill COM and native languages but recently announced more support for these languages as developers are no longer willing to commit to Microsoft frameworks.
People like Guthrie are just milking away the company moving from the next touted big thing Microsoft is investing its R&D dollars in. He's no different than Wall Street hedge fund managers smelling where the money is. What a leech!
Left by TAM on Dec 15, 2011 11:40 AM

Your comment:
 (will show your gravatar)

Copyright © andrewbrust | Powered by: