Summary: Posted the slides for my recent, unconventional talk, “Move Your Silverlight Skills to the Web with KnockoutJS.” And a note about web plug-ins like Flash and Silverlight.
I spoke at the Twin Cities Silverlight User Group yesterday afternoon on a rather uncomfortable topic: Silverlight’s imminent irrelevance. I told Silverlight developers they should stop writing Silverlight code and move to the native web. 🙂 It definitely raised some eyebrows.
If you’re a Silverlight dev, it’s time to move on. The war’s over and, for better or worse, web plugins lost. The native web is where it’s at.
Everyone was thinking it. Google was pushing it. Apple was pondering it. Microsoft was fighting it. (They aren’t anymore.) It was on everyone’s mind:
“Why Flash when HTML can do 99% of what we need?”
And that sentiment extended to Oracle’s Java and to Microsoft’s Silverlight. To every web browser plugin, really. Everyone was thinking it.
After all, why should users have to install a piece of software to view something in their web browsers? The path of least resistance dictates users will just not view that content, and, at some point in the future, technology will evolve and move on, leaving those barriers — Flash, Silverlight, Java — in the junk heap of failed and left-behind tech.
It was only months ago that we witnessed the first leap, the first bit of tech that deliberately left behind the barriers of Flash, when Apple took a bold leap of faith: no Flash or Silverlight on the iOS. And since iPad and iPhone were hugely popular consumer devices, this was sure to stir the waters.
People complained, developers gnashed teeth, consumers wailed.
But, here we are, a year later, and, it turns out, people are getting along just fine without those pesky plugins. HTML just works for almost everything. In fact, people are kind of liking this plug-in less idea. Google Chrome now renders PDFs not with a heavyweight plug-in from Adobe, but with just HTML. YouTube can render videos without crashy, always-updating-at-the-wrong-time plugins, but with HTML 5 <video> tags.
Web programming, on the other hand, looks and feels like decades of hackish attempts to bolt application development on top of a document display system. Probably because that’s precisely what the web is: intended for document display, warped and fashioned and hammered into something that resembles an app platform. Lot of warts, but then again, the web has always evolved that way.The perfectly-designed systems, though perfect, are always late to the game. HTML was first, and so it will win out. The plugin-less web wins because it was there first.
And that plugin-less web is coming, to be certain. It’s already here on virtually all mobile devices. Even Microsoft’s own Windows Phone 7 doesn’t display Web Silverlight content on their phones. If anyone was going to support Web Silverlight on a mobile platform, it was Microsoft. And when they built this new mobile OS from the ground up, they wisely chose to not support Web Silverlight.
If there was any doubt as to the future of Web Silverlight, this is the clear writing on the wall.
And to be certain, it’s true: Start Windows 8. Launch IE10. Browse to a Silverlight site. Ita-no-worksie. Why? Because Microsoft, as they wrote in last week’s blog post, are headed toward a future of a plug-in free HTML web, and that future starts with their new browser and new operating system.
Truth be told, it’s really a requirement for the whole Metro app security model to work: if plugins could run inside Metro IE 10, it would provide an easy way to side-step the whole security model: just write some nasty malware as a plug-in, have IE Metro execute it, and you just took over the Metro environment. I predict Microsoft will not renege, despite Silverlight developer protestations, on the “no-plugin” stance of IE 10. Windows 8 will be released with the inability to run Web Silverlight content through its default Metro interface.
Now it’s true, Web Silverlight, if you go out of your way to do so, can run be run on Windows 8: Boot Windows 8, launch the classic desktop “app”, launch the desktop version of IE, navigate to Silverlight site. Sure, that works, and thank you MS for providing that, but effectively this will render Web Silverlight irrelevant. Just think, what developer will build a site with Flash or Silverlight or Java, knowing their site won’t work in the default experience on the world’s most-deployed OS? (Not to mention the ever-growing plugin-less mobile devices!)
No one, that’s who. And that’s why Web Silverlight will be irrelevant in 5 years.
So where does that leave Silverlight developers today? In a surprisingly “angered but ultimately OK” position. Silverlight apps, already being a subset of .NET framework functionality, will map to Windows 8 Metro apps easier than any other platform: easier than WinForms, easier than MFC, easier than WPF, easier than Flash, Java, even easier than HTML/JS apps. Silverlight developers are actually positioned quite well.
Furthermore, Silverlight isn’t going away. It’s true Silverlight will be irrelevant on the web, but it still has a nice workable future on Windows mobile phones, which over time, will gain market share at the expense of Apple’s and Google’s devices. It’s only Web Silverlight that will be, and is already quickly becoming, irrelevant. Silverlight mobile, and Windows Metro apps are essentially a kind of Silverlight: XAML, .NET framework subset, self-contained, sandboxed.
Silverlight for the web is dying and will soon succumb to the same alive-but-irrelevant fate as Java applets. But the good news is, life for Silverlight developers is surprisingly bright in the XAML filled world of Windows 8 and Windows mobile devices. Technology moves on, and developers will follow, even if kicking and screaming, lest they, too, be rendered irrelevant.