views:

2849

answers:

7

I'm working on an application we made WPF instead of Silverlight as we wanted a full blown desktop application with the whole unique feeling and advantages that gives. However, with the announcement of Silverlight 4 I hear there is a buzz about Silverlight mostly being the preferred choice also for desktop applications.

So; why should I consider moving my WPF application to Silverlight 4 - given that I still want a desktop application?

+2  A: 

If your reasoning for WPF is that you want a full blown desktop app, then silverlight is not an option. If instead you are interested in a web-based app that can leave the browser, then Silverlight 4 might be what you're looking for.

From the wording in your question, it sounds like you want the full desktop experience, so Silverlight is irrelevant.

chills42
SL 3 can do that already, too, iirc.
Joey
True, but I think they've made some changes to allow a truly "out of browser" closer to the Adobe Air model.
chills42
I don't need a web-based app at all - will be used as desktop application anyway.. Yeah, the Out-of-browser experience was introduced in SL3, but from what I understood you can do much more in SL4 regarding desktop control, which is why it's more relevant to change now. But what features exactly are they referring to? (answer in new thread..)
stiank81
+9  A: 

I think your understanding of WPF and Silverlight is a little lacking. Silverlight is a subset of functionality and features that are found in WPF. Silverlight has a few features that are Silverlight specific. Silverlight on the desktop is simply a response to Adobe AIR by Microsoft. So with that said, implement your application with WPF if that's your choice. Don't let "buzz" drive your decisions about your application, that's what business needs and available skills in your organization should do.

Achilles
+9  A: 

Keep in mind that Silverlight 4 is currently in Beta with no end-user client runtime available. Silverlight 4 shipped in April of 2010. If you are already developing an app in WPF for the desktop, then it's probably the right solution. However, it would be wise to keep your ear to the ground and follow what's happening in Silverlight in case you may eventually want to port your app to the web space or develop a different app in the web space.

Silverlight 4 brings Silverlight to a whole new level. Check out Tim Heuer's blog post for a lot of the new features. Also, see if you can find a video of the facebook app from the keynote when Silverlight 4 features were announced. That app highlights a ton of the new features that are desktop-focused.

Ben McCormack
Thanks. Found the Gu in the Keynotes now. Will listen to what he has to say soon.. Developing a server side that will be the same regardless - and hopefully it shouldn't be too hard to port the client if we want to..
stiank81
Tim Heuers blog post was the answer I was looking for. Thanks.
stiank81
+2  A: 

A couple major reasons to consider SL4 over WPF

  1. Smaller framework size. Granted SL4 will probably be much bigger than SL3, but currently the Silverlight framework is about 1/10 the size of the smallest version of .NET 3.5.
  2. Cross platform support- Silverlight runs on Mac and Linux(in theory). This may not be a big issue to you but it is critical in some scenarios.
  3. Much better integration with HTML. Silverlight can live inside a web page and with version 4 html can live inside of Silverlight. Once again, this may not apply to you, but if you need to interoperte with exisiting web apps, Silverlight is definitely the way to go. It will also make it much easier to transition to the web is you need to.
  4. It's clearly where Microsoft if putting its energy. I wouldn't be surprised if WPF is pretty much dead in the water, much like Winforms and LINQ to SQL.
Jacob Adams
Scott Guthrie in the keynote said that Silverlight 4 isn't much bigger in size, the plug-in is still going to be right around 5MB on Windows.
Bill Reiss
+1  A: 

I can only see one two advantages to choose Silverlight.

  1. You really need cross platform, choose Silverlight.
  2. You need to embed something with HTML in a browser, choose Silverlight

Else if you need an Business Application that are working against web services, Why not use WPF with click once or any other technique to update the software?

The framework installation shouldn't be a big issue when its only installed once, not that big, and are already integrated in newer versions of Windows.

You gain performance, reuse of clr assemblies, and a very big issue for me is that you get full trust with for example reflection which is extremely limited in Silverlight both in browser and out of browser.

And I don't think WPF will die?? WPF have had all the stuff that are new in Silverlight 1,2,3 and 4 for a long time, and still have more. As I see it Silverlight is and always will be a lighter version of WPF for web browsers.

NPehrsson
+1  A: 

As Silverlight is a brand and is being heavily promoted by Microsoft project sponsers and funders are more likely to know it whereas WPF although well known by us will not be known outside the community.

So for future project development this may drive demand for SL4 over WPF particularly if there is a perception that Silverlight development is cheaper than WPF if the learning curve is less for a subset technology (although I don't agree with that sentiment myself).

Of course as far as your current app is concerned switching to SL4 would be nothing more than betting on being an early adopter unless there is a specific feature that you need that is in SL4 and not WPF.

I like the power of WPF but come SL5 I think we will all be on that bandwagon what by 2012?

Andrew
You make some good points, and it seems like there will be a growth in the use of SL - with many moving from Wpf. But the whole nature of SL really being webapps is doomed to give some restrictions that should give room for Wpf. At least for a while longer. But it sure will be interesting to follow the progress of Silverlight. And we'll keep our architecture open such that we can switch to Silverlight in the future if wanted - without too much problems..! The backend will be just the same anyway.
stiank81
+7  A: 

Choosing WPF or Silverlight or anything else for that matter on the basis that it is trendy seems to me to be just plain silly, unless you are trying to impress a girl or a pointy haired boss.

The purpose of writing software is to make money. That's why Microsoft does it, that's why I do it and presumably that's why you do it. While there certainly are people around who do it because they like doing it or in pursuit of lofty ideals, those people are not effective market forces and have no real say.

Most of the money is in line of business (LOB) applications and all the tools are built with the express purpose of selling them to people trying to build LOB apps, because that represents the bulk of the world's dev tools budget.

Silverlight up to version three essentially competed with Flash, which is to say that it was useless for anything but sparkle on websites: witness all the sample sites linked to the Microsoft Silverlight page.

Microsoft's big push in SL4 is support for LOB development; the RIA tools. But why? Because while you can do LOB development with HTML, CSS, AJAX, Flash and web services, that's a bit like saying you can build a nice car from a Meccano set, provided you're ready to use a lot of bog. Silverlight does the same things, but efficiently and coherently, with a unified development environment. And it's shiny.

This is a tremendous improvement over the shattered toolset for working with HTML, CSS, AJAX, Flash and web services, and if you're selling that integrated development studio, it's just marvellous.

Silverlight means easy rollout. What if they don't have Silverlight? They will, even if Microsoft has to stealth it inside the next service pack. Easy rollout is great if you're the IT dept, and great if you're selling bureau services. It's also great if you're developing because you don't have to muck about developing or testing setup kits.

For bureau type services there is no other sensible choice. For conventional LOB applicatons there is no reason not to use it and deployment is much easier and more convenient. if you need to do something outside those bounds, Silverlight is not appropriate.

It may be of interest to note that my application does a number of things (direct TCP stuff) not supported by Silverlight, and this is no problem at all; the server does them on the client's behalf and this nicely dodges all the environmental hazards surrounding in-the-wild deployments because we can control the server environment.

I think cross-platform support is a furfy, because Silverlight on non-Windows platforms lags far behind, and also non-Windows commercial workstations are few and far between. Businesses don't use Linux on workstations. Macintosh is not a platform, it is a religion: there's no point even talking to them.

All that said, pre-VS2010 there is no Silverlight designer. Hand-coding endless XAML is a colossal pain in the bum. SL4/RIA in VS2010 is wonderful but Joe Public doesn't have it yet and couldn't use it to roll out if he did, because there's no go-live licence or end user run-time.

This leaves WPF as the only practical option. However [drum roll] a final beta with a go-live licence and a run-time will be available Real Soon Now, probably end of February. Kudos to ScottGu and team.

Peter Wone
Weeell.. Won't chose it *because* it is "trendy", but if there is a buzz and Microsoft is focusing on SL WPF might be falling behind. In which case being "trendy" actually makes a difference. Thanks for some good points anyway.
stiank81
I honestly wouldn't look at hand-coding XAML as a "colossal pain", at least, if you come from an HTML background. I thought I'd hate it at first, but then I realized just how fast it really is.
rossisdead
Typing the tags isn't the problem. The prerequisite offhand knowledge of the semantics and interactions of hordes of attributes presents a tremendous barrier to newcomers. Then there is the business of bringing classes into scope. IDE support for this means that even though it happens that I do know how to go about bringing a domain data context into scope, it's still very much quicker and more reliable to drop a table on a designer surface and delete the resultant grid. I still -edit- the XAML directly.
Peter Wone
excellent response.
Theo Zographos