5 Reasons Why Silverlight Is My Preferred Web Development Platform
Posted by Davy Brion on September 5th, 2009
Item Solutions (where i work) has been using Silverlight ever since the first version came out, and by now we have quite a bit of experience and dare i say expertise in it. We generally suggest using Silverlight for every new project that we do, and the only time we don’t use it is when customers don’t want us to use it. This happens very rarely though.
While i generally don’t get involved in most of the UI stuff, i’m pretty happy with this because i seriously like Silverlight as a platform. Below is my list of top 5 reasons why Silverlight is my preferred platform for Web Development nowadays:
-
The ability to create an excellent UIX which definitely matters to customers.
We have some projects at work where the Silverlight UI definitely receives a “wow” response from customers. Not only because the UI is extremely responsive and snappy, but also because we can use new ways of visualizing data and enabling user actions in the UI in ways that are either completely new for web applications, or just new in general. We can easily create much more intuitive user interfaces with a responsiveness that can easily compete with that of desktop applications.
-
Low bandwidth overhead
Downloading the XAP file can sometimes be painfully slow, depending on your bandwidth obviously, but once it’s downloaded it’s also cached by the user’s browser. Everything that happens after that consumes very little bandwidth. There is no CSS, no HTML markup, no javascript, … the only thing that goes over the wire is the data that you actually need. And with Silverlight’s Binary XML feature you’re also using less bandwidth than before. This might not seem like a big deal to you, but bandwidth has a huge impact on the client-side responsiveness as well as your server-side ability to process requests.
-
The client is stateful again
This one is huge to me. We don’t have to deal with things like ViewState or SessionState or anything like that. If a client has retrieved a set of data, it can just keep it in memory if it makes sense to do so. This is especially useful for things like user-profiles, or static data that never changes but it has an impact on pretty much everything you develop. You can simply keep whatever data you need in memory, and it has no impact on the server at all. Well, it actually reduces the amount of data that you need to send to the server (or receive), and the number of requests you need the server to handle to implement the functionality you need client-side. This is pretty much a win-win for both the client and the server whereas with typical ASP.NET development, either the client or the server has to take some kind of a hit when it comes to maintaining state (even if it’s only a little).
-
The ability to write the client almost entirely in C#
I don’t know about you, but my HTML, CSS and Javascript skills are extremely limited. This seriously reduces my effectiveness when i need to make changes in the presentation layer in typical ASP.NET applications. And while my XAML skills aren’t what they should be, my C# skills are sufficient for me to be effective in client-side changes. I can easily look at a piece of client-side code and make whatever change i need to make without having to consult a reference guide. That’s not the biggest advantage to being able to write the client in C# though. Existing C# skills are very easily transferable to the Silverlight side of things, which means that a larger pool of developers is available to work on your front-end. True, there is a bit of a learning curve when it comes to Silverlight, but i’d argue that there is a much steeper learning curve to doing traditional client-side web development effectively.
-
It’s only going to get better
As much as i like Silverlight, it is by no means perfect and there is plenty of room for improvement. That’s normal though for such a young platform. In the future we’ll see plenty of new libraries and tools that will become available to Silverlight developers which should enable us to create even better web applications. Microsoft is investing a lot of money and effort into it, and i’m pretty sure that others will follow.
Now, you won’t hear me say that Silverlight is the perfect solution for every web application. SEO is still a problem, as well as acceptance of the Silverlight plugin in corporate environments (though this will only improve over time). But, in the situations where you can use Silverlight, it certainly pays off to do so.
September 5th, 2009 at 6:42 pm
Thank you for this post.
How about a post about reasons why Silverlight might not be the preferred platform?
Or, (false) reasons people avoid Silverlight?
I do like Silverlight, but I have doubts using it I know might not be factual. Things like browser support, how many people has installed the newest SilverLight, is Silverlight stable enough that new version of Silverlight will support my code, … Those doubts prevent me from using it or Flash and prefer HTML + JavaScript.
I want to know your experiences on these issues.
September 6th, 2009 at 12:11 am
Hi Davy,
I´m starting a Silverlight project from scratch next week. I´m currently looking for a simple framework to help us applying MVP/MVVM patterns.
Any suggestion? Caliburn? Prism?
Greets
September 6th, 2009 at 9:55 am
I have been working with SL since new year and think like you that many project will profit from using Silverlight.
I do think that SL is hard to learn, also because it’s such a young technology.
For us the greatest challenges hasn’t been choose between Caliburn or Prism. But implementing: datalayer, databinding (INotify..), undo, validation, working with getting data async. In short all the plumbing that CSLA and RIA Services is having.
We started with CSLA and NHibernate then we got tired of creating DTO and started sending the NH Entities to the client. Maybe this is a bad idea but it works for us.
To Davy
Can you write a post on the datalayer you are using? I guess that you are using NH and DTO’s? and maybe you can also share how you are doing input validation and undo.
September 6th, 2009 at 11:01 am
HTML 5 may be a bit of a problem. Not so much the way most think, because even with a canvas, it’s still slaved to that mess called javascript.
The problem with HTML 5 is that I think it could possibly strenthen Flash/Flex by doing something they are having a hard time doing… Threading!
HTML 5 comes with background threading, and that would make Adobe a bit more competitive.
Silverlight really only has one MAJOR weakness… Runtime Ubiquity! MS has to use the time between HTML 5 arrival, and Adobe integration of threading, to get this runtime to at least the 80% range.
We’ve had to go ASPX on a Navy project because nobody wanted to fight with their IT department to allow Silverlight.
We won’t be able to live with that for long, and may have to defect to Flex if Silverlight fails to gain runtime support.
I’m pulling for Silverlight!
September 6th, 2009 at 11:31 am
@Martin
We (I’m a coworker of Davy) use Davy’s Request/Response WCF service layer (he already has posted lots about that). And NO, we don’t throw any NHibernate entities over the wire. And YES, it’s a bad idea if you do so
September 6th, 2009 at 12:31 pm
@Harry
browser support is pretty good… on Opera it’s still problematic but everything else seems to work very well, except browsers on Linux
as for silverlight updates… we did have a few breaking changes with silverlight upgrades. a lof of them between 1 and 2, and a few minor ones between 2 and 3. I suspect that breaking changes will be kept to an absolute minimum from now on.
September 6th, 2009 at 12:36 pm
@Fabio
i only looked at Prism briefly, but that was only to investigate its ability to host multiple applications in some kind of a host app… i eventually just wrote that part myself because we already have our own MVP implementation, which is very similar to how we do it for ASP.NET WebForms.
So no, i’m afraid i can’t recommend one or the other… that’s not to say that i think they’re bad or anything, just that we already have most of the stuff that these frameworks offer.
September 6th, 2009 at 12:45 pm
@Martin
NHibernate, which sits behind our Request/Response WCF layer… none of the NHibernate entities are allowed to go outside of the service layer, so we pass simple DTO’s.
Input validation… i’d have to check to see how my coworkers do it, i honestly don’t have a clue at the moment
(does it show that i hardly do any UI coding?)
And undo management… if a user presses the cancel button, we don’t send anything to the server… that’s about it
September 7th, 2009 at 12:04 pm
[...] WPF & RIA 5 Reasons Why Silverlight Is My Preferred Web Development Platform Detecting design time mode in WPF and SilverlightGet Started with Silverlight 3 and Expression [...]
September 7th, 2009 at 6:57 pm
For a simple MVVM framework, I would like to suggest taking a look at the MVVM Light toolkit that i am taking care of, and of which i just published a new version. It is not as powerful as Caliburn, but it is easier to take in hands and start with. More at http://www.galasoft.ch/mvvm/getstarted
September 7th, 2009 at 11:08 pm
@Laurent Bugnion, I’ve seen your framework before, and didn’t install it because installation was difficult(to be kind).
However, I do see that you have a new MSI installation, so I’ll give it a go. Thanks for posting this because PRISM has been poorly launched by MS, and it also is quite large for smaller projects.
September 8th, 2009 at 4:09 pm
Just downloaded from svn the latest version of the Brion.Library to learn more about the request / response implementation.
I don’t see any async test for silverlight. Can you post an example on how to load some data from the silverlight client.
Thanks for all the great posts.
September 8th, 2009 at 4:12 pm
@Martin
yeah the version in Brion.Library is over a year old and hasn’t been updated in a long time… none of the silverlight stuff is in there.
I’ll write a post about the asynchronous version of the request dispatcher soon
(it’ll probably be sometime next week though)
September 11th, 2009 at 1:48 am
Davy,
Do you use Silverlight mainly for products used inside a company, or out in the public? How do you look at Flash/Flex/Air compared to Silverlight?
I’m facing the task to convert a .Net UserControl embedded as an object in the page, used in IE, to Silverlight.
September 11th, 2009 at 7:02 am
@Alwin
so far, we haven’t really used it on a truly public site (as in: anyone can sign up and start using it) yet… but we are thinking of redoing our company website entirely with Silverlight. Not sure when that’s actually going to happen though.
We do use it outside of the company, over the internet, if that’s what you meant and that works great… that’s why i seriously like the reduced bandwidth overhead
as for Flash/Flex/Air… i can’t really get into their technical merits (because i have no experience with them), but the market for Flash/Flex/Air developers is _very_ small, at least here in Belgium. Which is a pretty important factor as well
March 19th, 2010 at 3:11 am
@Martin and @Ben – passing “NHibernate” objects over the wire is NOT bad or wrong. The good thing is that SilverLight gives you a choice. Also, (and this drives me nuts) you are not passing DTOs. You probably are passing “View” objects.
Creating a view object for every object is silly. Create them where needed. Creating them willy-nilly complicates the application needlessly. I have a 2 large applications that use 2 View objects. They both work fine. I will probably create more for some performance issues. But these are NOT DTOs. The places i use them are when i am listing complex objects such as in a search results. Where as DTOs are structures that contain the attributes of single object, View objects contain some attributes of multiple objects.
Also, use NHibernate to create the view objects. I think the documentation refers to them as type safe objects. Like – “select new SomeViewObject(Id, Name,….) from Person
I have been using NHibernate/Hibernate since the original came out. I’ve used them both in web apps and “desktop” apps.
July 1st, 2010 at 1:40 pm
We are in the process of migrating a large intranet management information system over from ASP.NET to SL and we have encountered many hurdles and, in some cases, complete blocks. The main problem we have encountered is the comparatively slow performance of client side charts and grids when compared to their existing server rendered equivalents. In many cases, for example, the server side ChartDirector objects perform many times better than any of the downloaded SL graphing components we have tried. As most of our pages consist of these complicated charts it has really left us scratching our heads as to why we’ve taken this route of adopting SL. That said we like the programming model and we’re persevering…