Why I Would no Longer Choose Silverlight
I recently spoke to some of the wonderful guys on the ASP.NET team over at Microsoft (@shanselman @haacked and others). Somebody asked if anyone had any complaints they wanted to share. I brought up the topic of Silverlight since it’s been on my mind recently.
I would like to make it clear that the product we built with it is still amazing, and Silverlight has a lot to do with that. Silverlight is a solid product that has reflected the amount of effort that the developers put into it.
When I was originally confronted with the decision of building our user interface in Silverlight or HTML, I chose Silverlight for the following reasons:
- It’s the cool thing to do
- Perceived fast development
- User interface performance without having to touch “icky” JavaScript
Now that the first commercially available version of our software is available, I can’t help but admit some regret with the choice to use Silverlight.
The bottom line for me comes down to the fact that HTML runs everywhere, and Silverlight runs some places.
It’s becoming abundantly clear that the future of computing is in a wide variety of form factors, and they’re getting smaller. iPads, tablets/slates, iPhones, Android Phones, Microsoft phones, etc. are all widely available. Even Microsoft’s own Windows CE devices don’t support the Silverlight we know and love. These new types of mobile devices are showing us that the future it not just staring at a 19” screen. Our own Silverlight front-end is not only un-optimized for these devices, but worse yet, it doesn’t work, period.
So is the HTML story better? I believe it is. Let’s examine my original reasons for going to Silverlight:
- It’s the cool thing to do – I believe this gap is closing. jQuery and other animation and scripting tools are making cross platform development reliable and easy to develop. The proliferation of web standards has been helpful as well.
- Perceived fast development – My mistake here was thinking that since we didn’t have to deal with HTML, CSS, and JavaScript issues, we would be able to develop much quicker. The reality is that the time we would have spent on those issues is now spent dealing with another layer of misdirection. We now have to get the data from our database to the web server, but then we have to get it to the client. This is all while managing the subtleties of RIA services and LINQ to SQL objects. ASP.NET MVC removes one layer of mapping and complexity (we can optionally add layers obviously).
On notable exception to this is our scheduling interface. We’re using the wonderful Telerik scheduler, which really shows when Silverlight can shine compared to an equivalent HTML page.
-
User interface performance – Silverlight wins this one. We’re doing some amazing things with layout transforms that really wows our customers. The easy animations will be about the same amount of work in JavaScript, but the more complex animations will likely be easier in Silverlight.
Most of my reasons make common scenarios a wash (or possibly in favor of Silverlight). However, there are reasons that I’m avoiding Silverlight going forward:
- It doesn’t run well on Linux, CE, iPad, etc – This is huge. Unless you have a captive audience, you’ll want to make sure that your application runs on the newest devices. HTML is the only sure bet.
- Memory leaks/issues – This one really irks me. I’m sure that there are issues in our code that cause some leaks, and I’m sure some can be attributed to this seemly unsolvable issue. We have a screen that stays open on a touchscreen, and it consumes all the memory on the machine within half a day. The bottom line is that these simply don’t happen in HTML.
- Initial load hit – I know there are ways to mitigate this in Silverlight by spreading your application over multiple XAP files. However, HTML is the better choice for slow connections. The slow speed is spread throughout the screens, instead of switching between fast and slow.
In conclusion, all of the amazing reasons that I went with Silverlight have faded, and now I’m left with the reality of a platform that will never achieve 100% accessibility. There are plenty of situations where Silverlight may be the perfect fit, but next time I wont be as quick to lean toward Silverlight without serious consideration as to the potential audience and goals.
guest said,
Wrote on October 28, 2010 @ 1:15 am
Did you create something complex with html and javascript with supporting all major browsers?
Jaco Pretorius said,
Wrote on October 28, 2010 @ 9:45 am
In response to: Did you create something complex with html and javascript with supporting all major browsers?
Uhm, yeah – we do it all the time. It’s not always easy to get 100% coverage, but it’s possible. Have you created something insanely simple and straightforward with silverlight with supporting all major operating systems and browsers?
guest2 said,
Wrote on October 28, 2010 @ 10:00 am
>Did you create something complex with html and javascript with supporting all major browsers?
And did you create something complex with silverlight running all OSes supporting all major browsers?
guest said,
Wrote on October 28, 2010 @ 11:38 am
>all major operating systems and browsers?
MonoTouch, MonoDroid?
Bart Czernicki said,
Wrote on October 28, 2010 @ 12:27 pm
Very very high level comparison here…
If you are going to mention that it doesn’t run on Linux/iPad shouldn’t you mention you can run Silverlight out of the browser? You can access COM components? You run on Windows phone 7?
Performance? Silverlight can scale to 8 processors…that’s pretty freaking significant.
HTML 5 is coming but the tooling/dev is going to be a nightmare: HTML 5, SVG, CSS, JavaScript etc.
Personally I am not sold on the iPad. The phone..absolutely no one wants to carry 2 phones. What if I am creating a system that does ticketing? Would I create an iPad app, because one person owns an iPad or would I sell my Silverlight app as a tablet appliance on a Windows 7 tablet? iPads don’t let you customize the UI and have the stupid App Store…does not work if you want to do a Point of Sale system for example.
pete w said,
Wrote on October 28, 2010 @ 12:38 pm
You’ll no longer choose silverlight? Is that a generalized title designed to attract attention, or do you really mean to ditch silverlight as some sort of bizarre absolute?
Html/Javascript is the most mature, and almost always the best choice for public services.
Silverlight is almost always the best choice when you need an RIA app for corporate intranet in a company that already uses microsoft products.
You say silverlight is PERCEIVED faster development, but that statement is purely anecdotal based on your design. I have found MVVM light and RIA services to be faster with less code than MVC development, but again that is anecdotal and either route should be given consideration.
eglasius said,
Wrote on October 28, 2010 @ 5:36 pm
I mostly agree with this blog post, but I don’t agree with these:
“Memory leaks/issues … The bottom line is that these simply don’t happen in HTML.” not entirely true, you can get these when using HTML+JavaScript.
“Initial load hit … However, HTML is the better choice for slow connections. The slow speed is spread throughout the screens, instead of switching between fast and slow.” also an issue with HTML+JavaScript. It’s a different flavor of it, but I see these issues plenty of times on applications written by third parties. Appropriate care must be taken not to get this issue.
While I agree on moving to HTML+JavaScript, I’d say you need to pay attention to performance, otherwise you can face the issue regardless of your selection.
Since you’ll already be performance aware on your next project because of the issues you just experienced, you will be using a different development approach i.e. new/projects experiences won’t be comparable to your previous project.
John Price said,
Wrote on October 29, 2010 @ 5:30 am
If you want reach to be the most important decision, wouldnt you want to do more than 1 solution? People can turn of Javascript support in their browsers and you have a worse problem than you describe.
In the world of multiple form factors, isnt the best way to maximise reach to do, say, a Silverlight client that can take advantage of the power of the local client. But also a simpler, not as fancy, version that can be delivered by HTML? This also gives the added advantage of Accessability by less abled people using things like screen readers etc, increasing your reach even more….
Jason Young said,
Wrote on October 29, 2010 @ 8:12 am
“Did you create something complex with html and JavaScript with supporting all major browsers”
In our particular case, our target is all major *modern* browsers, which does certainly help.
“If you are going to mention that it doesn’t run on Linux/iPad shouldn’t you mention you can run Silverlight out of the browser? You can access COM components? You run on Windows phone 7?”
Pages in modern browsers can be pinned. Yes, our optimized iPhone site works on Windows phone 7. Our mobile site can even be run “out of browser” by using some of the original apple iPhone HTML app tags. Sure, there are limits.
“do you really mean to ditch silverlight as some sort of bizarre absolute?”
I’m going to try to avoid it unless I see problem in which it is an absolute perfect fit (captive audience streaming video perhaps?).
On memory leaks –
Sure, they can happen in HTML & JavaScript, but they usually don’t persist. The issues in SilverLight can persist between pages in the application.
“People can turn of Javascript support in their browsers and you have a worse problem than you describe.”
I used to have the same concern, but they’re far more likely to have JavaScript than Silverlight.
magellings said,
Wrote on October 29, 2010 @ 12:40 pm
Windows Phone 7 won’t support HTML 5…it supports Silverlight though! MS put very little work into the browser on WP7. And…generally a site is redesigned for a mobile device anyway. Who wants to use the same site on such a little screen? As long as your data is in the same place, use HTML/jquery/css for mobile devices with a view appropriate for those devices…use Silverlight on the others. Use the same data and domain logic with both.
corporation offshore said,
Wrote on January 18, 2011 @ 6:06 pm
.This topic describes the reasons that application developers and component authors for Silverlight might want to create custom dependency properties. Prerequisites .This topic assumes that you understand dependency properties from the perspective of a consumer of existing dependency properties on Silverlight classes and have read .
Andrew @ Bespoke Software said,
Wrote on January 4, 2012 @ 10:39 am
I’d have to agree with you on the memory leaks. It’s unbelieveable how it consumes all the memory on my machine within half a day.
(The same reason was why I left Firefox and moved to Chrome)