Why Silverlight Ambiguity is a Bad thing for Office 365

In my post yesterday on next generation SharePoint speculation, I surmised that Silverlight is beginning to look a lot like Microsoft’s ginger-headed stepchild. (yes, I went there) I’m definitely not the 1st or most pessimistic person to talk about the Silverlight roadmap. Checkout MossyBlog who was originally the Silverlight lead or something important like that. I would be pissed too if I became a Silverlight expert and champion only to see this ambiguity and trepidation arise around the technology.

This all seemed to start around the iPad release. The big news was that it didn’t support flash cause well, flash is a powersucker, crappy technology, and deep down inside I think Steve Jobs would like to buy Adobe and burn it to the ground. That’s great, but what was missed in the news is that no browser plugins were supported on the iPad. That’s because plugin’s suck and Jobs set us all on a path of HTML5 love touting universal device support. Unfortunately, HTML5 is just barely supported by anybody at the moment so it was a bit early to pull the plug-in (see what I did there) but here we are anyways.

It’s still very early but with Windows 8 adopting this brave new HTML world and Office looking like they will do the same one has to wonder what will happen to Silverlight now. I’m a very late adopter of Silverlight. It was way after this all started when I created my 1st real Silverlight project. Here’s why Silverlight is great and why it’s potential demise is a bad thing for SharePoint Online/Office 365.

  • Everyone is scared to build Silverlight apps now – With so much fear out there over the roadmap every would be Silverlight project is now becoming a sandbox solution or some sort of HTML/jQuery monster. This is good in that people will be prepared for the future, but bad in that these projects could have been completed much faster or more feature rich in Silverlight.
  • Silverlight is special. Silverlight runs on the client and with that comes a lot of flexibility. For example, if you are developing for SharePoint Online you will quickly discover a load of limitations with sandboxed solutions and even out of the box web parts. It’s safe to say that we live in a web services world and most developers instantly think web services when they think cross-platform or client/server integration, but web service calls from SharePoint online no worky. However, since Silverlight runs on the client it’s game on for web services.
  • If you deployed a sandbox solution that was used by more than you and your Mom you might have discovered something called points. Points are arbitrary counters of resource utilization. These counters consist of things such as processor utilization and database calls. What is concerning is how ridiculously measly a point is. I was dismayed that even the most simple event handler consumes massive numbers of points a day. By default (if memory serves) your Office 365 site only gets 400 points by default and somewhere around (50,000) to be used by any and all site collections you deploy. I could easily see this getting used up by an application that actually does something useful for a bunch of users. The great news is that when you deploy Silverlight applications they don’t count against your resource allocation.
  • Silverlight dev is well fun. I find Silverlight to be a pleasure to code. That’s because it’s easy to mock up an application in Visual Studio or Expression Blend then extend it out to do something more than look pretty. It’s about the XML or  XAML in this case. Working with XML is just easy and it’s something sorely missed in traditional technologies.

With all that said, it’s not like Silverlight is going to disappear before the next version of Office 365. That means we have a while to worry about it, but who wants to build an application when  they know they will have to refactor it not 2 or 3 years down the line. This is a big problem. Don’t believe me. Go check out the Office 365 marketplace. Known as Microsoft PinPoint to us partners. A quick peruse of the listings reveals a surprising stat. There are few if any real products listed. Most “products” are really just smoke and mirrors for services efforts. Why? Cause it’s unclear how these vendor on-premise solutions can be refactored to work with Office 365. You might even be surprised to know a few vendors have set up listings with no actual products just to gauge interest. It’s certainly unclear how to package and deploy these solutions like an app. The marketplace may become an app store one day, but it will not be this day.

For me own products, we are considering porting them to Silverlight for Office 365 because of the aforementioned advantages with the main disadvantages being lost time and lack of iPad support. We hope Microsoft will do us a solid and keep XAML around for a while. Perhaps not as a plugin deploying, iPad sucking, second-tier technology, but as Microsoft’s best way to deploy HTML5 compatible applications. That would be a great story indeed.


About jmikewatson

Co-founder @ SnazzyPrise
This entry was posted in Uncategorized. Bookmark the permalink.

3 Responses to Why Silverlight Ambiguity is a Bad thing for Office 365

  1. Pingback: SharePoint: Rumors of My Demise have been Greatly Exaggerated | jmikewatson

  2. Pingback: Office 365: Links Worth a Look for Tuesday, August 9th, 2011 « My Central Admin

  3. Pingback: The future of Windows dev is here? | jmikewatson

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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