I recently set myself the task of developing two versions of a simple coverflow control - one in Silverlight and one in JavaScript. The completion of the task provoked the following tweet…

…which surprised me because I have much more experience developing .NET applications than JavaScript.

In hindsight the tweet was probably a little unfair. The JavaScript version only works in WebKit browsers and I suspect it’ll require quite a lot more effort in order to improve its browser coverage, whereas the Silverlight version should already work, as it is, in any browser provided there’s an appropriate plug in available.

It was still interesting to go back over and compare the two implementations, so I’ve written a CodeProject article which gives a high level overview of the two implementations and gives some thoughts as to what might have contributed to the above reaction…

“For an exercise of this nature, the static type checks and better tooling support available when developing the Silverlight version didn’t seem to have as big an impact as they might on a larger more complex project. However, the streamlined feedback & debugging experience of the JavaScript development did make a big difference.

“Being able to change some JavaScript and simply refresh the browser to see the effect of the changes is a big advantage. Also, using the in-browser debugging tools to examine the state of elements and experiment with different values for their attributes while the UI updates ‘on the fly’ helped to quickly understand & solve many problems.”

Head over to Code Project if you want to read the full article. Also, you can see the two coverflows in action here:

• JavaScript version (WebKit only)
• Silverlight version