WPF vs XBAP vs Silverlight... which suits business applications?

Question

I'm pretty familiar with a lot of the ins and outs of full fledged WPF client applications. I know that WPF client applications supports the full .NET Framework 3.5, allows for hardware acceleration of 2D and 3D graphics, theming, templating, styling, triggers, the works.

What I'm not clear about is what features, and/or niceties are either present or lacking in XBAP and Silverlight applications. I've heard that XBAPs are intrinsically limited in certain ways due to security concerns, but that's about it.

I know for a fact that WPF is robust enough to be used in full-scale business applications, but what about XBAP and Silverlight? What are the significant capabilities and limitations of each? Do either of them lack features that would render them useless when used in a business application?

Answer 1

I don't have experience with XBAP, but my impression is similar to yours in that it's only restricted in terms of security when compared with WPF.

As for Silverlight: I recently used it to develop a complex agricultural telemetry monitoring user interface--it's more of a data visualization app than a traditional business app, but it has plenty of CRUD and there wasn't a single feature that I wanted to implement but couldn't because of my choice of technology. And that was SL2.

I'm sure you'd end up with more bells & whistles if you used XBAP, and if you can guarantee that your users are running .NET 3.5 (or is XBAP part of 3.0 too?) I'd go for it. Otherwise, I'd have no reservations in recommending Silverlight.

(Apologies if you wanted more of a feature comparison matrix--but I think you can find those at Microsoft.)

Answer 2

Wintellect wrote a good comparison between Silverlight and WPF published here: http://wpfslguidance.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28278

From personal experience in WPF and Silverlight I've found that SL is fully capable for LOB apps. The .NET RIA Services are an excellent addition to SL3 for LOB apps. To answer your last questions, there is nothing in my experience that holds SL back from creating LOB apps. The only significant difference between WPF and SL in this discussion is that SL doesn't have access to the local resources on the client machine such as the registry and can't access Windows specific features that WPF can such as Windows 7 jump lists or libraries. I think Silverlight is the best choice for biz apps due to ease of deployment and ability to target multiple platforms.

Answer 3

With regard to Silverlight, I'll outline my experience so far. (NB: Re-reading this it sounds a bit negative, but I'm pointing out the missing features. Overall I like Silverlight, a rich UI in browser using c#? Rocks).

Notable differences are there's no right-click, mousewheel support, print functionality and you can't open a new window. Your OOB SL app can't sit in the notification area. You can handle the mouse events in javascript but not if you want your app to move OOB.

The SL team also seem overly concerned about security to the point of gimping its LOB suitability (no new windows, trust settings for local system access in OOB, notification area, etc.).

Some of these make a Silverlight app feel like it's not windows compatible. Think about highlight text, right-click copy. Or right-click paste. These basic operations which lots of people use are missing. It also feels like an alien UI experience, e.g. you instinctively go to scroll a grid with your mousewheel and it doesn't work. This stuff works in any table in a browser, but not SL.

Programming wise, I haven't used WPF much, but as far as I can tell, there are some significant differences in how you have to attack some problems.

Markup Extensions are missing in SL. It also only has integer indexed binding, so no property bags without some tricks. There are no triggers so you always have to write code to wire up events (irritating in more dynamic pages). It's got no inheritable styling, apart from the ImplicitStyleManager in the toolkit, which isn't up to the job.

So for certain LOB apps it's fine, for others you have to jump through a few hoops (e.g. if you want customisibility for the client). But it's certainly not great for ALL LOB apps.

My impression is also that SL doesn't feel finished yet, there's a lot of niggles. For example, the datagrid is frustrating (doesn't auto-stretch, very difficult to subclass), autocomplete box a bit erratic, navigation framework a bit clunky, combobox/treeview hard to bind (they really haven't sorted out if you want to bind SelectedItem to a different object to the itemsSource).

All in all, Silverlight's almost there, it's fine as long as you're prepared to accept a few limitations and niggles.

Answer 4

I tried to do XBAP development for about 18 months full time for a fairly ambitious project and absolutely hated it.

There are many undocumented limitations, such as not being able to set a custom mouse cursor. MS forgot to tell anyone about that one and a hundred others. I'm very averse to sandboxing now because of that minefield.

Combined that with the deployment nightmares (still to this day there's not a good story for Firefox, even after 3.5 SP1 there's still problems), I honestly believe that MS is doing everything it can to kill XBAPs in favor of Silverlight. I don't blame them, just wish they'd have been more open about it.

I would avoid XBAPs like the plague. It's a dead scenario with no future. Wouldn't be the least bit surprised if they were deprecated soon.