I've got to decide which technology to use for a larger app that's mainly used in a LAN (therefor a win-app), but should have some components that are to be deployed via the web (for home-workers).
A few years ago everybody shouted 'hey, use WPF', but nowadys it becomes really quiet on WPF and everybody seems to favor silverlight (which, to my narrow knowledge, is able to work outside the browser, to). Even MS itself advertises it's Expression Blend as tool for creating Silverlight-apps and one has to dig deep to even find the word WPF in their ad's...
So, what do you think? Is there any recent(!) comprehensive comparison between both (SL vs. WPF) or at least documents that shows the path MS will follow in the near future?
Microsoft has an new strategy for Silverlight, look at these article:
or in German:
I Think for an Desktop application is WPF the best technology for the next years.
I'm not a fan of apple (even thru the iphone and ipad are nice)
They don't except the one man show for Silverlight.
I do like the way silverlight works, it looks alot like WPF and programming for windows is almost the same as programming for web. Two worlds come together.
With HTML 5 i don't have that feeling.
... to emphasize, he wasn't clear i guess..
silverlight is not dead at all and still going to be cross-platform
yes, my post was a little bit quick.
Rocky also has an Statement to this in his blog.
the bomb has fallen... the media kills silverlight... Well i do have my doubts now, so much damage has been caused just by saying that HTML 5 is the only true cross-platform tech.
Search on google for "Our strategy with Silverlight has shifted"
So many discussions and commotion..
We're about to create a dynamic rendering frontend, we aint sure if it's going to render xap / baml / etc now.. maybe just plain old html or xml / xsl transformations
ok, ok, that's for Silverlight, but what's with WPF?
Is it still MS's favorite technologie for windows-apps? It started as the big brother to SL but nowadays?
Reading "Silverlight is a core application development platform for Windows, and it’s the development platform for Windows Phone" (Bob Muglia in his corrective blog-post) makes me worry about the investment to dig into it and manage the learning curve...
This type of topics are all very tragic to me, I have spent sooooo many hours on my weekends and days after work trying to catch up with all these new technologies (such as WPF) that I find it really depressing to hear all these bad news about these technologies possible being dropped just like that… specially when they are so relatively new! But I can understand why these topics keep coming back over and over again.
Regardless off, my cheese predictions are……..:
1. Silverlight will fade away sooner than later (for anything other than Windows Phone 7 programming) and we will see tools by Microsoft that will make programming HTML5 simpler. --- If you want to target all devices then I think we need to face the fact that HTML-X will be the way to go.
2. WPF will continue to be the dominant technology for building Windows specific applications --- I am guessing this because WPF has very few limitations on what you can do on Windows.
Who knows what would end up happening but its really stressful for me to see all this changes happening so incredible fast!
It depends on what you're trying to do. Wpf has a ton of new features in .Net 4. Compare to WinForms, which has very little.
I think the media spin on Silverlight is just that; spin. Siliverlight has always (to me at least) been pushed as a way to deliver rich media and business applications through the browser to a large target audience. I don't think anyone said it would (or should) be an alternative to Html 5. So if you're doing a business application and don't have control over the desktop, Silverlight would still be appropriate.
On the flip side, if you only care about the Windows platform, I personally would go for Wpf. Sliverlight can do LOB, but its also a more restricted runtime, and I believe that's true even for OOB applications (less restricted, but still restricted). So why not use the full power of the desktop?
I stil get the impression that SL and Wpf are evolving separately, but as evidenced even recently in .Net 4, the best of one eventually make it to the other (for example, the VSM from SL3/4 is now in Wpf 4).
We are developing a WPF application, slowly. It is my worry that a direction change in Silverlight could lead to Silverlight consuming WPF.
WPF will always have a deeper integration with windows then silverlight can have.
Not quite as much as the windows API, but they can be invoke'd from WPF.
It depends if u need to integrate with for example Office (thru it is possible with desktop deployment)
Silverlight will have limitations because it's simply running in a sandbox.
Mike Taulty drew a picture which shows the platform integration
That is true, but it all depends how much integration with Windows you actually need. They already introduced COM Interop and out of browser. Office Interop where you can integrate with either Windows office or Mac office would be nice and may happen. That may reach >75% of LOB applications if not more.
Did u read this excelent post from pete brown?
WPF is not dead at all, quote from the post:
This all adds up to some key points on WPF:
Folks who know me know I'm just as much of a fan of Silverlight as I am of WPF. This post covered the future of WPF, for the future of Silverlight, be sure to read the Future of Silverlight post on the Silverlight team blog. That post does a good job of explaining how Silverlight fits in to the changing web landscape.
Also, a year ago, I put together a post about the future of Silverlight and WPF. That's still a good reference when combined with the updates to guidance in this post.
fwiw, here's how I view these things.
Silverlight is the primary smart client technology going forward, because it reaches Windows, web, Windows Phone and embedded devices.
However, each specific platform has extensions or specialized bits of functionality for that platform. So each time it is Silverlight + ???.
WPF as a brand may or may not have a future. But WPF as a technology will likely become Silverlight + "good stuff for Windows".
At the PDC in 2009 Microsoft said clearly that WPF and SL would converge over the next few years. We already see some of this in SL4 and WPF4, and I expect we'll see more now that the two teams merged (which happened months ago actually).
And this all makes sense if you think about it. As developers we don't want two (or more) dialects of basic XAML. But we do want to tap into the unique features of Windows or the phone or whatever. Which directly implies that there'll be extra goodies available depending on your platform.
Following that train of thought, I would surely expect Windows to have all sorts of cool stuff - which WPF does. But if WPF and SL converge to a common core set of XAML - then I ask you: what is the difference between "WPF" and "Silverlight with Windows extensions"?
At that point it is not technical, it is branding. And let's face it, the "WPF" brand has little going for it, while Silverlight has momentum and energy.
Of course much of this is speculation on my part - they may decide to keep the WPF brand (ugh) to molify people's fears. But regardless, they've made no bones about the convergence strategy - and that's exactly what we really, really need them to do.
To be clear, I've had enough of binding mode on WPF being twoway and SL being oneway by default - how stupid is that? This is the sort of thing convergence should fix. Similarly, why does the ListBox in SL have all those cool states, but the WPF one is totally lame? Again, convergence should say they have very similar states so I can use the same animations on both platforms.
However, each specific platform has extensions or specialized bits of functionality for that platform. So each time it is Silverlight + ???.
Mmmmm, I think you are spot on Rocky.
I have been desperately doing some research regarding this WPF / Silverlight is death issue. I am about to start a pretty big WPF project and I would be pretty pissed if Microsoft decided to face out WPF later.... of course, they will never say they will decommission WPF but they will probably stop enhancing it.
After watching the following video:
Its becoming more clear to me that WPF is probably going to die.
The first hint (on the video) is that Microsoft keeps insisting that you should start with Silverlight until you hit a wall and then move to WPF.
Then, it turns out, Microsoft will be coming up with some WPF control that will allow Silverlight content to be hosted on WPF. So basically, you do all you can do on Silverlight and if you run into a wall, then fire up WPF where you can host your Silverlight content and extend it some way or another through WPF.... I guess.
I think I may end up going for a Silverlight solution, only problem is, my app requires accessing local database, doing some automation with Microsoft Visio and other things. I wonder if I am going to run into some impenetrable wall .... and then what.... what options will I have?? damn it, I am pissed.
I think you are missing the point of what I'm saying.
I am saying that I think the brand of WPF might fade away. But the technology of WPF won't fade away.
Assuming WPF and SL have the same core XAML dialect, but WPF has lots of additional stuff specific to Windows, then what is WPF? It is a superset of SL for Windows. And what is SL? It is a subset of WPF that works across different platforms.
Does that mean WPF went away? Of course not. Does that mean SL went away? Of course not.
Don't confuse possible branding/naming issues with real technical issues - they aren't the same thing.
Or to put it another way - more tangibly useful perhaps.
When approaching an app project, I default to Silverlight. However, there are possible requirements that may cause me to switch to WPF, including:
Yes, I know that some of these things are addressed by SL in out-of-browser mode and/or trust mode. But honestly, if I really think my app will be used frequently offline, I'm going to want a client-side database with data sync capabilities - and that means SQL CE and that means WPF.
Similarly, sure I could get at specialized hardware using a COM component that I call from SL. But that means the user has to install the COM component - so why not just use ClickOnce and install the whole app in one shot? Again, this leads me to WPF.
thanks for contributing to this discussion.
First of all I think many people are somehow disturbed by MS's product policy. Back in the days when WPF's launch was not that long ago, it seems that WPF was the superset to SL (do you remember: WPF/E, the one with the smaller footprint) and THE choice for a winforms guy (like I am) to start with. Beeing a 'late adopter' and having to decide now where to go, I'm puzzled, because everybody says 'start with SL (and only move over to WPF, if necessary)' . Remember, I'm not a 'browser guy'. Do I have to manage XAML AND all that browser-stuff, I never needed, because desktop apps are my target environment and SL is so much browser-related (is it?)? In fact In know more than one team dropping WPF in favor of WinForms.
Just think of a developer asking his boss for investment in WPF or marketing your his/her new application, written with WPF. 'Do you talk about that technology/brand/product, MS has recently dropped in favor of SL?' Or the book I bought recently: 'Pro WPF with...' Could/should it be renamed to 'Pro SL with...' without major changes?
It may be about technology, but 'what's in a name'? Surely a lot (otherwise they shouldn't have choosen two different ones!) at least to the public!
Greetings & take care
The "what's in a name" question is a good one.
There's no real investment in a name like WPF or WCF. They aren't standalone products, they are just features within a bigger product. In other words, .NET is the brand, they are just constituent parts. There is little or no marketing budget behind the term "WPF", because it is marketed as part of .NET. And from what I understand, there's litlte marketing budget around .NET either, because the primary dev tool is Visual Studio - and that has an entire marketing team.
There's an amazing investment in a name like Silverlight, which is not only a standalone product, but is partially consumer-facing. There is a huge marketing budget around Silverlight, not only to help drive development, but also adoption through things like the Olympics and the NFL (American football).
It was a really big deal when "WPF/E" was reinvented as Silverlight. Not only because of the big technology shift, but also because of this major branding/naming/marketing shift.
So you are right, there's a lot to some names, which is why "WPF" is comparatively expendable, and Silverlight isn't.
Again however, branding and marketing have relatively little to do with the actual technology. The important thing to understand, I think, is that the WPF and Silverlight teams merged a few months ago, so there is only one product team working on this stuff from a technology perspective. So it is a good bet that they won't want to maintain and enhance two completely separate products, therefore it is natural to think that they'll try to converge the technologies as quickly as possible.
To answer your more tactical question, the way I use SL and WPF there is no meaningful difference between them. My MVVM demos, for example, are mostly the same across WPF, SL and even WP7.
There are places of direct difference however, depending on how you structure your user experience.
I think the thing to understand, is that while SL runs in the browser, it is a smart client technology. It is far more like WPF than like HTML. In fact it is virtually identical to WPF in most ways that matter for a business app.
The technical differences include:
Again however, I come back to the same thing - I always use as little of any platform/technology as necessary to get the job done. SL is a subset, so if I can get the job done with SL then that's the best thing to do (I can always upsize to WPF later if necessary). If I can't get the job done with SL, I'll use WPF.
In my mind it is a superset/subset decision - always default to the subset that meets your needs.
As long as you understand both technologies, you can architect your UI so transitioning from SL to WPF is relatively easy (the other way isn't always so easy - because your WPF code might use superset technologies).
I started playing around with Silverlight this past weekend. I spent about one hour playing around with it, which is the most time I have ever spent playing with this technology..... Needless to say I am still very, very, very new to SL.
I immediately noticed things such as the dependency property support on WPF appears to be far superior to the one found on SL (no read-only dependency properties on SL). Binding also appears to be more powerful on WPF too. No support for logical tree on SL etc.
Now, I realize that there must be all kinds of workarounds for the lack of these missing features and that some other features may not be needed if you implement patters such as the MVVM pattern…. but whats wrong with having all this extra power I ask??
I also couldn’t find support for multiple windows on SL, something I need to be able to support multiple monitors.
But I do think SL can get the job done, I just personally feel a little bit apprehensive toward SL primarily because I am not familiar with it and I fear the unknown
On another thought, I wonder if part of all this Microsoft obsession and focus with SL is driven by Windows Phone 7. I can only assume that Microsoft sole purpose in life at this time is for WP7 to beat the number of applications offered by Android and iPhone so that they can gloat about it. And since SL is the tool to use to build WP7 apps then everyone is on top of that platform.
In any event, I hope that SL and WPF do converge in the NEAR future (like next week) because that is they way to go. I only wish Microsoft just posted a clear and concise road map of what a heck are they planning on doing regarding WPF / Silverlight / HTML5 etc.
Copyright (c) Marimer LLC