Silverlight or Html5 - from A .NET developer perspective.

Html5 vs Silverlight for the .NET developer :

If you are already invested in .NET, then you have been honing a particular set of skills for the past decade. This puts you at a position where it is difficult to favor Html5 simply because you lose some agility and sometimes this may make all the difference.

Since MIX11, there is much debate with regard to Html5 vs silverlight. And developers continue to ask, what should I use. When I try to make a decision on the technology to use and power my applications the following facts helps me consolidate my ideas and beliefs further and this is also my current state of mind.

• Silverlight is cross browser / platform

Note: This is great news if we are comparing silverlight to wpf but when compared to html5, we can agree on one thing. Html5 will be available on many more devices so it's not actually a pro for silverlight however, it's good to note that silverlight runs on those devices where it counts :

All major browsers on both the mac and windows are supported. *nix support through Novell mono moonlight, which currently lags a bit behind but don't let this be a show stopper for you. You can easily develop a secondary slim version that works for moonlight which currently fully supports version 2.0 of silverlight and one that supports 3.0 is almost complete.

Depending on the features your using, you might even be able to provide support for your application in it's full glory or perhaps with a minor workarounds if this audience is very important to you. Finally you also get to target the mobile platform wp7(Currently html5 support is lagging on wp7).

• Strongly typed languages support (c#, vb.net). Unlike losely typed languages, you will benefit greatly from compile time error checking, and many language specific features.

• Easy deployment --your compiled silverlight assembly includes the compiled code and xaml files for all your pages in your application. These files are embedded as resources and are compressed. While this is the default, it's also very flexible, meaning you can split your code in modules that can be dynamically downloaded by your silverlight application upon request. Tip: Prism is a great library if you want to benefit from modularity among other things in your silverlight apps.

• First class IDE support. Not only are you benefiting from superb IDE support for both designing your applications in expression blend while doing the development in visual studio, but your way of working changes very little if you are already a developer in the microsoft space. Note that we will soon see some pretty good IDE support for Html5 as well, so this particular con for html5 won't hold true for very long.

• Reuse existing known code patterns. Patterns and practices have been gathered over the years and are a way for us to reuse "experience" in our development. Some are our own, some are industry known patterns and practices. On the other hand, Javascript too has been around for a very long time and they too have adopted their own set of patterns and practices, but clearly as a .NET developer, with silverlight, you don't have to relearn anything. I do heavy development in both c# and javascript, so this point is pretty moot for me, however, it's an important decision maker when chosing the right technology.

• Reusing existing code --You already have existing code written for the .net framework, be it code that simply executes on the server or perhaps a WPF desktop application. Porting this code to run on the client instead in silverlight is much easier than rewriting it from scratch in javascript.

• As a web developer, you write client-side code for Silverlight in the same language that you use for server-side code (such as C# and VB), similarly you will be able to leverage the same objects you use on the server, so : generics, LINQ, Lambda, collections and many more even though only a subset of the .NET framework classes.

• IE8, 7 and 6 support is important to you because you still have a lot of clients on these browsers. This is a given in silverlight, yet these browsers currently do not support the html5 featureset. Using another third party plugin such as google frame to target content to this user group ( also currently constituting the majority) is out of the question. Why should the largest portion of your userbase be served in downlevel?

• Install and upgrade --fully managed install and upgrade mechanism in place for Silverlight. This means as new versions of silverlight are made available, we can start using them in our applications right away and based on the runtime version of silverlight your applications are built against, that version will be used or the user will prompted to download and install it. This is fully managed by Microsoft and you do nothing in this department other than some minimal configurations such as MinRuntimeVersion and so forth.

Counter this with Html5, where features that constitute Html5 are supported at the discretion of the browser vendor. This means each browser vendor will pick up the feature they think is useful or important and will implement it. This makes it quite easy to find a feature that works in one browser but doesn't work in another or simply a feature that works in the latest versions of the browser while your left working around to compensate for the feature loss in older versions.

In fact not too long ago whatwg has officially moved to a non-versioned model where Html5 is simply known as Html. This move by whatwg makes sense to me also because no browser currently supports the entire featureset of Html5 and therefore the name is misleading. Infact no browser ever supported html4 completely. Silverlight, being a plugin does not suffer from this lack of feature uniformity across browsers/devices.

Final notes : 
One thing is sure, Html5 has been a hot topic for a while now and with the release of ie9 it has gotten even hotter. This is a fresh area with room for plenty of innovation and new business opportunities to tap into. Like all new things, there's a gold rush. Everybody is pushing out web applications that uses shiny new Html5 features, because that is the current trend and there's lots of room for investment. This is a large market segment with a wider audience.

As a .NET developer, if you are selling development tools, you are no longer confined to Microsoft developers, instead suddenly the web is your oyster. Lastly, it makes the headlines to invest in Html5 at this early stage, which can quickly translate to free marketing for you. That's someting to consider as well.

So, in the end, which one is the better? Today I'm confident about my silverlight investment because it made sense for my application and it's needs. However on a different project, I may sing a different tune all together. Sadly, there is no better choice. You know your application, only you know what it needs.

For instance I developed Abmho based on need. I couldn't find a proper syntax highlighter on the web that simply worked, that wasn't riddled with adverts and one that didn't require me to make a request to the server everytime. Soon this became irritating and so I decided to make one myself.

It was important that my syntax highlighter executed in the browser as an application and was fast and responsive. I also wanted to complete development fast and I have a .NET background. I also already had a syntax highlighter library in c#. Rewriting this library in javascript would have simply taken forever. It was certainly not worth the effort.

This move allows me to ship a wpf version (currently in the works) that requires subtle minimal changes to get working as a full fledged desktop application that I will be making available soon since Silverlight is a subset of Wpf. All this wouldn't be possible if I had gone the Html5 route.