JavaScript vs Silverlight

by Justin Meyer

JavaScript vs Silverlight

  

Justin Meyer Recently, we've found ourselves part of a Silverlight vs JavaScript debate. I think that JavaScript is a better long term approach to web application development. But, I found myself stumbling the first time I needed to articulate my reasons. It was just a gut feeling. But after spending a few minutes sketching my thoughts, I've proved my intuition to my brain.

posted in Development on March 18, 2010 by Justin Meyer

Recently, we’ve found ourselves part of a Silverlight vs JavaScript debate. I think that JavaScript is a better long term approach to web application development. But, I found myself stumbling the first time I needed to articulate my reasons. It was just a gut feeling. But after spending a few minutes sketching my thoughts, I’ve proved my intuition to my brain.

There are 3 main reasons to not use Silverlight: future web development needs, development time, and user experience.

The Future

  • Plugin Lock-In – When IE started to suck, it started loosing market share to better browsers. This was only possible b/c IE ran off accessible standards. It’s unlikely that someone will develop a “better” version of Silverlight. What happens if Silverlight doesn’t get updated for 10 years, just like IE.

  • HTML5 – HTML5 is going to provide a lot of the same goodies that Silverlight provides. It already has support of Google and Apple.

  • Group Standards – Yes, group standards move slow. But things seem to be picking up lately. however compare IE’s DOM standard to the W3C’s. Oh, don’t forget IE’s implementation -> Damn you Peekaboo Bug!

  • Competition – With Flash, Flex, Titanium, JavaFX, Silverlight is not at all the clear winner. There is only one JavaScript.

  • Backend lockin – If you want to develop flex, you pretty much have to be running WCF services from a .NET backend. The great thing about Thin Server Architectures is that your back end becomes replaceable.

Development Time

  • Tools – I’d rather use Firebug than the overweight Visual Studio any day. Also, errors from other people can be much easier tracked.

  • Open – There is tons of open-source JavaScript code to learn from. jQuery won open-source project of the year!

  • Community – I’ll admit I am not down with the Silverlight community. But there are tons ofJavaScript meetups and conferences.

  • Scripting vs Compile Languages- Scripting languages produce less code. Less code almost always means more maintainability. But, this is a matter of preference. I just don’t think Compiled wins by default.

  • Testing – It’s very hard to test silverlight. Selenium does not work.

User Experience

  • Percieved Performance – Load time is pretty much the most important thing to a user. JavaScript lets you progressively load only what you need to. This is more important than smooth animations in IE6.

  • In the Box – Silverlight is mostly trapped in its box. Either this, or you have to make the entire page silverlight.

  • Mobile Support – Good luck getting this on an iPhone.

  • OS Support – There’s a project for it for Linux. But considering how bad flash is on Linux, why would Silverlight be different?

  • Plugin Download and Install Base – Currently about 50% of people have Silverlight. Are you going to make 1/2 your users install the plugin?

  • Accessibility – You can’t highlight text.

Phew, that was quite a diatribe. There are some good reasons to use Silverlight / Flash … when you need to do something that JavaScript can’t do. Also, some considerations should be made to your organization’s skill set. Otherwise, stick with JavaScript.

  
Contact Us
(312) 620-0386 | contact@bitovi.com
 or cancel