There’s been a lot of talk recently about Silverlight – in particular comparisons to HTML (JavaScript/CSS). Unfortunately a lot of these comparisons come down a catfight over whether one is better than the other. The truth, of course, is that both have their place and the challenge is in fact deciding when to use one technology set over another.

Simone believes Silverlight is limited to desktop, Windows Phone 7 and niche extensions to traditional web applications. Despite his (IMHO false) assertion that HTML/JS/CSS can do almost as much as Silverlight (deserves a separate post to address this wildly inflated claim – come on Simone!) – I actually agree with his definition – however, I would further comment that the “desktop” is not the same as it was when we all wrote VB apps and installed them on our user’s (Windows only) desktops, one MSI at a time! The new desktop now covers, mobiles, televisions, Windows & Mac desktops, Xbox and are growing markets that Silverlight is in a great position to make an impact in.

So I decided to write down the scenarios that I believe might compel you to choose Silverlight. Not in any particular order,

  • You need the power of the desktop but delivery of the web – historically the rise in popularity of HTML based applications was driven by the easy in which applications could be updated and distributed. Simply update a few files on your web server and auto-magically your clients had the latest version. Silverlight gives you this same power and in addition your users can control whether/when they upgrade. Technologies like MEF and Prism also allow you to modularize your applications to allow for selective downloads/upgrades depending on a user’s permissions.
  • In fact, I’d argue that Silverlight out-of browser with elevated privileges is where it becomes a completely different beast to HTML applications. If also raises the question of when does Silverlight become WPF or perhaps more importantly when do we stop seeing them as different technologies and start talking about XAML applications that can target either the desktop or browser, share a common set of assemblies, but depending on the target can reference specialised enhancement assemblies.
  • You’re building a graphics intensive application – kind of a no-brainer really. Sure you can use the newly supported canvas tag and some fancy JavaScript libraries but it’s a drop in the ocean to what’s possible in XAML and C#.
  • Your application needs to operate outside the sandbox of the browser – there are some restrictions you simply can’t get round in the browser, primarily for security reasons. You can’t access information on a user’s computer, you can’t write to a user’s disk (other than cookies and HTML5 offline storage), you can’t access devices connected to your user’s machine – by running Silverlight out-of-browser and/or with elevated trust a lot of these restrictions are lifted.
  • You need to interact with the device your application is running on – in addition to the comments above there are an increasing number of scenarios where your application needs to communicate with local devices. As mobiles, televisions and other devices become more important for business and consumers the applications that run on them need to be more and more advanced. You want to be able to integrate cameras, webcams, scanners, printers into your applications and the browser’s sandbox won’t allow this.
  • Your application needs to stay alive – there are lots of examples of applications that need to keep running but are still connected to the internet – email clients, twitter, face-book and IM clients, monitoring applications (for say networks, stock prices...). These applications typically need to stay alive at all times and notify you when things change – like display a toast notification or give some audio feedback. While you can achieve some of these features in HTML I don’t know many people that would prefer to use a browser twitter client over a web based one – it’s just not the same.
  • Your application needs to take heavy use of state - HTML5 has add local storage which (if you’re a .NET coder) is similar to Session State management in ASP.NET but instead controlled by the browser. But this is a long way from the statefulness (not a word but let’s make it mainstream!) most of use have forgotten after years of web development. Remember when the applications we built didn’t have to make a server request to load a new view? Or being able to Imagine being able to browse to a different page without making a server request. Imaging being able to store state in memory
  • You need your application to look exactly the same on all platforms – because each browser interprets your HTML in order to render it to the screen it is not possible to guarantee your pages will render the same. Sure they’ll be close but if you application relies on pixel perfect rendering Silverlight is a better choice.
  • Your application needs to work offline – HTML5 has made some cool advances here but it does seem a bit simplistic – you basically get to nominate pages that should be available offline and these will be cached and served locally. In Silverlight OOB applications the only thing you are typically doing over the wire is communicating with services to process data – everything else is done locally anyway with no requirement to be online. You can continue (or switch) to storing data in Isolated Storage or in disk in user folders, pages can be navigated to and rendered as normal. Like an offline HTML application you “simply” need to proxy your service requests to handle being offline – and I know I’d rather be doing this logic in C# not JavaScript.
  • Your application needs to consume/create media – again a no brainer – even with HTML5’s video tag there is so much more available in Silverlight – you get smooth streaming, multicasting, editing, video brushes and unlimited rendering options for your player.
  • Your application needs to support multi-touch – in Silverlight you can detect multi-touch interactions from your users in HTML it can’t.
  • You’re building a game – sure you could (if you really wanted to) build Pong in JavaScript but if you want to create anything serious then Silverlight is a good alternative for a .NET coder that doesn’t want to learn Flash/Action Script.
  • Your application needs to be highly performant (again not a word but should be one) – I’ll admit I haven’t done any tests myself but others have and it seems that in general Silverlight is faster than JavaScript for graphics and processing.
  • It’s also true that your users will find a Silverlight application to navigate around since it doesn’t need to perform server page request – this can make a huge different to both real and perceived performance of your application.

I’ve deliberately stayed away from questions over whether solutions are “easier” in Silverlight/C# versus HTML/JavaScript/CSS – at the end of the day it comes down to your team’s experience and knowledge of each technology set.

But I personally love the fact that in Silverlight I get to code entirely in C# – both on the Silverlight client and in services on the server. I also love not having to worry about page requests, session management, browser compatibility (as long as Silverlight is supported I’m good to go), page weight (ViewState anyone – in Silverlight I just don’t care!), unit testing JavaScript (possible but yet another framework to use and support – in Silverlight you can use one testing framework for client and server and stick with it), page lifecycle (especially in ASP.NET not so bad in ASP MVC), session timeouts, state…

So there you have it – anyone else have any reasons they would/do use Silverlight?