5 reasons why Silverlight sucks in LOB (compared to WPF)
As I said in previous post, I’ve started at home blogging about the accountingLOB applications in Serbia and one of the questions I got challenged by one of my readers (who knows how BIG Silverlight fan I am) is
“Would you be using Silverlight for your own accountingLOB application?”
Initially answer looked very clear to me: with all the improvements Silverlight 4 brought to LOB game, desktop like programming model and web deployment looks like a perfect fit for public facing application (outside of intranets)
But, after doing some more thinking on this subject, to my surprise I came up with the opposite conclusion:
WPF is better choice for serious LOB applications.
And here are 5 most important reasons why I think like this:
Silverlight 4 is not cross platform environment any more
The biggest advantage SL had over the WPF (in my mind at least) is ability to be deployed to non-windows machines (MacOS and Linux powered machines).
Having Silverlight 4 with a whole slew of COM+ dependable features virtually prevents creating a Silverlight 4 siteapplication which would run on Mac and Linux. At least, that is the state as of today I am aware – somebody please correct me if I am wrong in this.
The way I see this change is that Silverlight 4 is shifting toward being unique “cross-screen” (desktop, mobile and TV) platform which is perfectly fine with me just it doesn’t have any particular value in context of LOB applications).
UPDATE: I did found a couple of folks with Mac which were kind enough to tell me that on Silverlight.net site there is Silverlight 4 plug-in for Mac which (as long as COM+ features are not used) works fine.
Silverlight adoption rate is not good enough
According to later RIA Stats adoption rate of Silverlight is around 60%. I’ll put aside the fact that I am not seeing that number around me in Czech Republic and accept it as correct one with slightly different interpretation: 40% of PCs are not having Silverlight installed.
The funniest thing is that WPF has 99% adoption rate because every PC with Windows newer then Windows XP SP2 (including Vista and Windows 7) has WPF installed on it. I am not sure how many Windows 2000 and Windows 98 machines are out there but whatever the number that is personally I don’t think anyone should care targeting that segment as very unlikely to invest any money in purchasing your LOB product.
Even if a PC is not having the .NET framework at all, the download size to get it on PC is just 28 MB which is bigger then 9 Mb size of MacOs Silverlight 3 plug in but who cares (with any non dial up connection it is matter of seconds). In my personal opinion, this is one of the most important WPF features in .NET 4 🙂
Silverlight tooling is good enough. WPF tooling is better
Starting with VS 2010 and Blend 4 we can work in SL4 and Silverlight is getting much more attention (just look at the paces of silverlight and wpf toolkits and everything gets to be clear there) but using WPF allows me to use all of the memory profilers, dbg viewers, any framework I want etc. If you are in doubt what exactly I think with this here’s an example: Silverlight does support printing but in case of serious LOB applications you need all the muscle WPF offers. Think something like Crystal Reports for example.
Silverlight programming model is more constrained then the WPF one
Doing Silverlight applications, one is forced to adopt the “make async web service call and get a chunk of data and do something with it” which in my personal experience limits the productivity of LOB developer compared to the speed he has developing with WPF . There’s no direct access to DB (which is actually great) but that ignores the fact that some LOB applications might need just that. For example, application can be written to target local SQL CompactExpress which then is set up to replicatemerge deltas with the central enterprise server. Anything like that (and we know how this things can get crazy in enterprises) is not possible in Silverlight.
Another thing related to this is aspect of offline access. I am aware that Silverlight 4 does have isolated storage and yes it has a bunch of open source DBs sitting on top of it, but it is just a single user storage. In reality, quite often in serious LOB applications we are seeing office andor P2P network topologies where it is essential that you have a “proxy per office” or ability to sync directly the data of “user X”. I know that Sync Framework is coming for Silverlight in 2010 but it is not there now and I am not sure if it would support topologies other then client <->(Azure) server.
Silverlight is still technically inferior to WPF in some areas.
Read Brian’s post to see what this point is about.
Now you heard 5 of my most important reasons why I choose to stick with WPF on this. Am I missing the point? Making a false statement? Do you have more reasons in favor of WPF or Silverlight?
Looking forward to hear the comments 🙂