Before moving onto the next phase of this blog, however, I thought it might be worthwhile closing off the previous chapter, given that I had focused heavily on Silverlight, with a bit of a wrap up and a retrospective of Silverlight – a post-mortem if you may. I think people tend to forget what a challenge it was to develop applications for the web just a few short years ago, and now unfairly (in my opinion) malign Silverlight and those who used it. I’d like to set a few things straight, or at the very least detail my perspective on it, if I may.
Why Silverlight Received Traction
Silverlight had its roots in WPF, which automatically made it appealing to WPF developers. Rather than just being bound to Windows, WPF developers could transfer their existing skillset to developing applications with Silverlight that easily deployed via the web, and could also run on Apple OS X!
I was not a WPF developer at the time – instead I had been developing various web-based business applications using ASP.NET WebForms and the Microsoft AJAX Toolkit. These applications worked, and impressed clients and users, but it was certainly primitive and flawed.
Remember, the ASP.NET MVC CTP only appeared at the end of 2007, and didn’t hit V1.0 until March 2009!
My interest in Silverlight started in the Silverlight 2 Beta days (mid-2008), before Silverlight had a clear business application focus. However, I immediately saw its potential in this area, and started writing articles on the SilverlightShow.net website in 2008, specifically targeting building business applications with Silverlight – one of the first, if not the first to do so. Silverlight enabled me to write well-structured applications using C# on both the server and the client, and create rich user experiences with ease, without worrying about cross browser concerns. Remember, this was a time when:
- IE6 was still an extremely popular browser.
- HTML5 support in browsers was still a long way off.
- CSS rendered inconsistently between browsers, and was limited in features.
- Libraries like knockout.js, backbone.js, require.js, breeze.js, etc didn’t exist yet.
- Single Page Applications (SPAs) didn’t really exist (beyond GMail, which had the support of Google behind it).
- Frameworks like angular.js, durandal.js, and Ember.js didn’t exist yet.
- All the browsers behaved differently, and testing was a nightmare. (It still is, but less so)
- Mobile devices were not widespread. It’s hard to believe, but there was a time when most mobile phones weren’t able to browse the web, and tablets were big clunky things running full Windows. The iPhone only came out in 2007, and the iPad only in 2010.
- Browser plug-ins were used widely – particularly Flash.
- Installing the .NET Framework needed a 100+mb download, when Silverlight was only a 5-7mb download.
The above factors contributed to making web application development a nightmare. This made Silverlight a very attractive platform for us as developers. Silverlight started getting much more love from Microsoft than WPF had ever seen, and was rapidly gaining traction with developers accordingly. Microsoft’s message was essentially “if you’re building business applications for the web, you should be using Silverlight”. WPF was getting little to no attention, and Silverlight was getting lots, so given the choice it made sense to focus on that instead of WPF. Especially given that from version 3, Silverlight was obviously much more focused towards business application development than WPF was. It had a DataGrid (for better or worse) long before WPF, validation summary and validation styles on input controls, a DatePicker control, PivotViewer control (from version 4), the Visual State Manager, RIA Services, text in WPF was fuzzy and gave users headaches (until .NET V4.0 fixed this issue), and it could run on Apple OS X. They are just some of the benefits off the top of my head. Interestingly, Silverlight has many features that even “Modern UI” applications (i.e. Windows 8 applications) still don’t support.
Why Silverlight Started to Lose its Shine
Silverlight was inevitably misused at times. I personally never saw Silverlight as being suitable for use on public facing websites (with the exception of sites that could take advantage of its awesome streaming video support), but I strongly believed in its ability as a solid technology for building web applications upon. As in, data centric applications which typically (but not always) ran within a corporate network. And it suited this scenario very well. But it would obviously provide a barrier to entry when it comes to the “drive by” nature of web surfers on the open web.
Silverlight also had a perception issue. People were expecting it to be something it was never realistically going to be. In particular, there was a desire for Silverlight to run on mobile devices. Unfortunately, that was just never going to happen, and some saw that as being an indicator that Silverlight had failed. That said, given the rapidly rising use of Apple Macs and the fact that it ran on these machines meant that it still had a major advantage over WPF.
And Then Everything Fell Apart…
Silverlight was still getting a strong focus, marketing, and love from Microsoft, until suddenly it just stopped. Just like that, it disappeared overnight, and no-one from Microsoft could be drawn in to talk about Silverlight and its future. We’d heard some rumours that Silverlight may not have a future, care of ex-Silverlight program manager Scott Barnes (aka @MossyBlog), and this appeared confirmed when Bob Muglia, president of the Server and Tools division let it slip that Microsoft’s “strategy has shifted” toward HTML5.
Mr. Praline: I’ll tell you what’s wrong with it, my lad. ‘E’s dead, that’s what’s wrong with it!
Owner: No, no, ‘e’s uh,…he’s resting.
Mr. Praline: Look, matey, I know a dead parrot when I see one, and I’m looking at one right now.
– Dead Parrot Sketch, Monty Python’s Flying Circus
The silence on Silverlight’s future spoke more than words, and was the worst thing Microsoft could have ever done. The resulting unease and uncertainty inevitably led to the ecosystem collapsing, with tens of thousands of developers suddenly left out in the cold. Not only were developers cheated, but the effects extended to:
- Contractors and development shops who had projects cancelled
- Authors whose book sales fell through the floor
- Component vendors who had invested heavily in developing components that nobody wanted any more
- Businesses who had invested in a technology that had no future
Having personally invested greatly into Silverlight, and falling into multiple of the above categories, I was one of the thousands that felt the repercussions.
It’s interesting to now see companies that promoted Silverlight to their clients and had developed many Silverlight applications now marketing themselves as specialising in migrating Silverlight applications away from the platform.
My Position on Silverlight’s death
I am still, to this day, monumentally pissed off with Microsoft and their handling of Silverlight’s demise. It just never needed to be as bad as it was. I personally felt that Silverlight had reached a reasonable maturity by version 5, and didn’t really need to go too much further. Actually, I think Silverlight went too far in a number of aspects. In particular, adding 3D support to Silverlight 5 was completely unnecessary. It added to the runtime size, I suspect it was the reason for Silverlight 5 being released so long after Silverlight 4 (18 months), and I’m still yet to see any application that ever used it.
That said, Silverlight was never perfect. These points from Paul Stovell about WPF all apply to Silverlight too, and are quite valid criticisms.
I do miss the Silverlight PivotViewer control though.
Microsoft obviously had the foresight to see this, however, there was no reason why Silverlight needed to die. All it needed was an inclusion in the product line roadmap (a minor and drawn out release schedule would have sufficed), some acknowledgement as still being an important part of the Microsoft family of products, and some continuing promotion of its value as a business application platform. The silence from Microsoft just reinforced the consensus that Silverlight was dead. I can’t think of a worse way to handle this scenario that could have caused any more damage than it did.
The damage that’s been caused extends far beyond just the Silverlight ecosystem. The damage also extends to a major loss of developer faith in Microsoft as a platform provider, which can’t be understated. This is especially important in an era when their flagship operating system (Windows 8) is struggling to gain traction, while its key competitor (Apple OS X) is surging in popularity. Simultaneously, mobile devices and open technologies like the web are becoming more and more capable, and tying people less to Microsoft platforms. I’ve discussed with numerous fellow developers how we’ve each lost the faith required in Microsoft to invest our personal time in their newer technologies – ultimately this will only hurt Microsoft.
My Experience in the Aftermath of Silverlight’s Demise
I lost a few things when Silverlight died. Firstly, I lost my hard won standing in the developer community – suddenly nobody was really interested in what I had to say any more. I had been running the Silverlight Designer and Developer Network, but numbers fell away rapidly, until it was no longer viable. I refocused on building WPF applications, and eventually onto HTML5 applications. WPF wasn’t being advanced, so there wasn’t a lot to talk about there, and I was far too new to the web development community in order to stand up as an expert (because I wasn’t).
The one thing, however, that saddened me the most was what happened with my Silverlight 5 book. My Silverlight 4 book had been well received, but I felt that I could do much better. So I practically rewrote it (adding 200 pages in the process) for Silverlight 5. I was (and am) so proud of what I had accomplished with that book – it is so much better than the Silverlight 4 version. I carefully crafted something that was really well structured, well written, and would guide developers through building business applications with Silverlight without getting lost. The few reviews I got backed that up. If you haven’t written a book (and I typically recommend against it), it requires a massive amount of effort. I worked 7 days a week, for 6 months on it (fitting a job in-between). Unfortunately, it was all for nothing, as few people ended up buying the Silverlight 5 version, given that it came out after the doom and gloom hit the Silverlight ecosystem. Sales fell flat (as happened for all Silverlight related books), and all the effort I put in was not rewarded. As it is, most of the copies sent to me by the publisher are still sitting in the cupboard (pictured), and I don’t really know what to do with them all, as nobody wants them. If you’re interested and are in the Sydney area, let me know – I’d be happy to give them away to anyone who will use them.
The Future of this Blog
I now plan to start posting a lot more on this blog. I’m still focusing on business applications for the web, just the technologies used will be different. I will throw in some posts about WPF and other topics at times, but the key focus will be on building applications using native web technologies. One thing I’d like to do is some video tutorials, and I hope to include them as a part of many posts where appropriate. I’ve got a lot of things to blog about (my last project alone generated 111 ideas that I noted down to blog about) – let’s see how I go getting through them!