From Experience, Silverlight Versus HTML


I built a personal UI framework for SharePoint 2010 using Silverlight 4 called Xaptic (its still possible I’ll upgrade to SL5) for assisting me with UI/UX prototyping and some personal learning. Of course, I also harbor an ongoing interest in raising its level of usefulness, architectural robustness, and overall stability. I would certainly not move forward supporting multiple versions of Xaptic – I could not raise its level of usefulness, architectural robustness, or overall stability knowing that any technology I wrongly adopted now appeared short lived, or slowly withering away. Of course, this is the essential issue set before us. If Microsoft, in a sudden burst of disclosure, spilled their strategy beans I doubt it would change my thinking at this point.

“…ay, there’s the rub, For in that sleep of death what dreams may come” – William Shakespeare, Hamlet

I wanted to understand how I should proceed with Xaptic so I built two versions with nearly identical form and features and learned a few things along the way.

  • I agree with those who say Silverlight is technologically 10 years ahead of anything available in the current HTML5/JS realm for these reasons
    1. For Xaptic, runtime performance (minimal jerky motion, unexpected pauses) was excellent. HTML5/JS feels more dependent on external influences.
    2. Cross browser consistency was damn good in Silverlight – for HTML5/JS I had lots of trouble making things work across different browsers without carpeting layers of JavaScript API’s. The exception here is mobile browsers which largely do not support SL (except WP7)
    3. Frankly, Silverlight coding patterns feel more traditional (yet updated), time honored, and adaptable to the newer paradigms that XAML offers. HTML5/JS feels like a box of chocolates by comparison.
  • The asynchronous patterns in Silverlight are as much trouble as anything JavaScript throws at me. So that was a draw
  • Debugging in both technologies is not a great experience in many ways. Another draw.
  • Interestingly, load time for the initial page was better in HTML5/JavaScript. HTML5/JS wins
  • In “Xaptic for Silverlight” I called REST Services that I created myself reading from a SQL Database. In “Xaptic for HTML5/JS” I used SharePoints client object model to R/W from lists. My overall coding effort was the same for both technologies. A draw.
  • For HTML5/JS, really good libraries are often free to use (MIT license) but SO MANY exist. With Silverlight, good third party components cost money but you know what you’re getting. I give this one to HTML5/JS
  • Silverlight – hands down – has much better and consistent tooling support as would be expected coming from proprietary origins. I felt that pain as I built “Xaptic for HTML5/JS”. Silverlight wins easily here. HTML5/JS is a hodgepodge of anything anyone feels like building.
  • Of course, Silverlight does a few things VERY WELL while HTML5/JS does most things reasonably well.        


In terms of building a true LOB applications for the enterprise (using SharePoint 2010) I want to point out how the two major development approaches (I describe below) offered by SharePoint 2010 influenced my final recommendations and its relationship to my decision around the Xaptic project.  

A very nice feature of SharePoint 2010 is the ability to construct web parts from HTML/.net, Silverlight/.net, or HTML/.js (assuming the appropriate API and services are provided). A big difference between building/using individual web parts in SharePoint versus a full blown LOB application that uses SharePoint as a “platform host” stems from “atomic” nature and variety of web parts that SharePoint offers. With a strong understanding of business requirements and of the SharePoint platform itself a business user could develop what traditionally took programmers months to accomplish. Let’s call this the “power user” style of development for now.

Conversely, hosting a vertical LOB application within SharePoint tends to focus and refine the technology stack very early on, as well as any middle tier logic required. Only a peripheral use of web parts could/would be needed to finish off any of the low hanging fruit. A highly integrated and fluid UI for some LOB application hosted in SharePoint could rapidly move away from the standard web part model now offered by SharePoint 2010. In fact, the efficacy of hosting an LOB application within SharePoint would be a legitimate question in many of these cases. Let’s call this the “integrated” style of development for now.

Silverlight is a prime candidate for the “integrated” approach because it not just a web part technology. It has all the components needed for application development – navigation, dynamic loading of modules (MEF), styles, layouts, threading, VS templates for business, etc. It’s a full stack.  

Oh, wait just a minute. I seem to recall that HTML5/JS also has navigation, dynamic loading of modules (XML/JSON), styles, layouts, threading (Web Workers), and now with VS2011 has templates as well. In fact, that’s the technology SharePoint is built with (in HTML’s previous generation)…

Back to development for a moment, the “power user developer” is much less reliant on any one technology or component killing his/her entire effort. You can leverage web parts built using Silverlight, pure HTML,, and JS. If one of those technologies fall out of corporate favor (or fails unexpectedly) you simply pull it out of rotation and fix it, or buy a third party web part that still gives you that “Pie Chart” the boss needs. Pie charts in JavaScript, Silverlight, or Excel look the same. Yes, I realize this is highly over simplified but you get my point.

Here are my recommendations based on my recent experience.

  • Build LOB/Enterprise applications with HTML5/JS even if you need some specialized feature that Silverlight happens to offer. The reason is simple, you can make Silverlight a small widget of “special functionality” within a larger HTML5/JS application. You get the best of both worlds. For Xaptic, I decided to use HTML5/JS as the platform but create/utilize Silverlight widgets for any intense graphical stuff – could be fun.
  • If you’re building a small department application with less technical savvy then utilize platforms like LightSwitch or even MS-Access (remember, an MS Access database can now be uploaded to SharePoint as a fully functional application site – not my first choice but possible)
  • HTML5 is evolving fast, mothball projects that are fully based on Silverlight but retain Silverlight for specialty needs within the same project.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s