Future of WPF/Silverlight

[Paul Stovell]

Hi all,

With all the PDC announcements about Silverlight 4.0 it seems people are starting to ask what the future holds for WPF.

Lester has been running a series on WPF 4.0 features:

http://blogs.msdn.com/llobo/archive/tags/New+WPF+4+features/default.aspx

Tim Huer has a list of new Silverlight 4.0 features:

http://timheuer.com/blog/archive/2009/11/18/whats-new-in-silverlight-4-complete-guide-new-features.aspx

Comparing the two lists I can't help feeling that WPF isn't getting the love. The WPF features seem small (effort-wise) when compared to Silverlight features like printing support. That said maybe the WPF features were very time consuming to implement and they just appear small from the outside because they did such a good job of making it look easy.

Another thing I'm noticing is that while Silverlight is still catching up to WPF, it seems to get better implementations when it does, and they don't make their way back to WPF. For example, WPF XBAP's can request full trust as can Silverlight 4 OOB applications; but the Silverlight application gets a nice prompt - the WPF app crashes with a loud siren until you can convince system administrators to update group policy while simultaneously patting your head while rubbing your tummy and reciting your times tables.

I'd love to understand more about why this is. Are the Silverlight features just really easy to build? Or are the WPF team purposely waiting for Silverlight to catch up to get better parity? Or is it simply that the Silverlight team has hundreds of developers while the WPF team is really just David Teitlebaum and a handful of interns that keep him stocked with caffine while he works his graphics magic?

And what do you think the future holds?

--
Paul Stovell

[Josh Smith]

I think that WPF will, in hindsight, be seen as a proof-of-concept for Silverlight.  MSFT is promoting Silverlight far more, and better, than they ever promoted WPF.  Once Silverlight catches up feature-wise with WPF, the web-entrenched world will have no need for a Windows-only platform that targets the desktop.

With that said, I'm speaking in generalities.  There are still plenty of companies that want or need desktop apps, or, don't want or need browser apps.  So, there will still be opportunities to work with WPF, but they won't be nearly as common as Silverlight gigs.  That's my guess, at least.

Learning WPF and then moving to Silverlight is like learning C++ and then moving to C#.  So, be glad you know and love the bigger, more complicated framework!  :)

Josh

[Sacha Barber]

Thats a very interesting view point Josh. Very intersting indeed.

 

Like you say lucky for us we know the bigger more complicated brother

--
Sacha Barber
sacha....@gmail.com

[Colin Eberhardt]

Hi Josh,

This is an interesting thread ... and I think I agree with your that
WPF will be eclipsed by Silverlight. However, I don't think it is
simply because Microsoft are pushing it harder (which is certainly
true).

In my experience, in the financial domain, there is very little
interest in WPF, however with Silverlight it is a different story.
Interestingly, Silverlight is not just being talked about by the
developers but by their project managers and those more senior in the
company. Ask a director if they have heard of Silverlight and they
will probably say 'yes', but ask about WPF and you will get a very
different response.

In my opinion the reason for this is quite simple. What does WPF offer
over and above their usual desktop solutions (which are typically
Excel or WinForms)? skinning? rounded borders? In the financial domain
this is hardly a priority.

Whereas Silverlight offers something of a new frontier. The directors
are well aware of the cost of developing RIAs. It costs much more
money and takes much more time to deliver the same application over
the web than it does to the desktop, as developers do constant battle
with AJAX which retrofits an interactivity on top of a framework
designed for delivery of static, hyperlinked documents.

Silverlight offers the potential to deliver RIAs, using developers who
will already be familiar with the language, at a greatly reduced cost.

This, to me, is the reason why Silverlight will win. (In the financial
domain at least).

Regards,
Colin E.

On Nov 20, 12:35 am, Josh Smith <flappleja...@gmail.com> wrote:
> I think that WPF will, in hindsight, be seen as a proof-of-concept for
> Silverlight.  MSFT is promoting Silverlight far more, and better, than they
> ever promoted WPF.  Once Silverlight catches up feature-wise with WPF, the
> web-entrenched world will have no need for a Windows-only platform that
> targets the desktop.
>
> With that said, I'm speaking in generalities.  There are still plenty of
> companies that want or need desktop apps, or, don't want or need browser
> apps.  So, there will still be opportunities to work with WPF, but they
> won't be nearly as common as Silverlight gigs.  That's my guess, at least.
>
> Learning WPF and then moving to Silverlight is like learning C++ and then
> moving to C#.  So, be glad you know and love the bigger, more complicated
> framework!  :)
>
> Josh
>
>
>
> On Thu, Nov 19, 2009 at 3:46 PM, Paul Stovell <p...@paulstovell.com> wrote:
> > Hi all,
>
> > With all the PDC announcements about Silverlight 4.0 it seems people are
> > starting to ask what the future holds for WPF.
>
> > Lester has been running a series on WPF 4.0 features:
>
> >http://blogs.msdn.com/llobo/archive/tags/New+WPF+4+features/default.aspx
>
> > Tim Huer has a list of new Silverlight 4.0 features:
>

> >http://timheuer.com/blog/archive/2009/11/18/whats-new-in-silverlight-...

[Peter O'Hanlon]

Colin - much as I respect you, and I do you know, what WPF offers is much more than a pretty interface. 1st class databinding means that it's easier to develop data based applications than WinForms/MFC/pick your desktop platform here. This ease of development, lowers the development time and, hence, decreases the time to achieve the ROI. As a business owner, being able to deliver critical systems in less time, and at lower cost than the competition, means that we are getting more bidding opportunities because of it.

 

There's a common misconception that all companies want browser based applications. In the environment we tend to operate in, browser apps are distinctly frowned upon, so WPF will long have a place with our clients.

--
Peter O'Hanlon

[Sacha Barber]

Just my 2 cents here.

 

Infusion and Lab49 both want WPF developers right now, but do not seem to be wanting as many Silverlight folk. I actually work for a finance company and we use WPF for many reasons not just because it gives us round borders (which we do like of course). I have to agree with Peter, WPF definately has it's place, but I can see that SL is being heralded as the one to go for, for me that is sad news, I will of course do SL if I must, but to be honest, still do not like it that much. WPF is freakin awesome, and there is still loads missing from SL, ok new things get added to SL, but for me these are gloss and the real missing parts are still missing.

 

I still see WPF jobs coming up, good ones as well, and if all the devs out there want to do SL, great, I will stick with WPF and up my rate. Winner

--
Sacha Barber
sacha....@gmail.com

[Colin Eberhardt]

Hi Peter,

I was being deliberately obtuse, paraphrasing the perception I believe
non/semi-technical people have of WPF.

Personally I think WPF is bloody marvellous, and it is the first
technology that has driven me to write a blog and evangelise.

I agree with you to a point about WPF theoretically resulting in
greater productivity and reduced cost, however, I would struggle to
prove that to anyone who controls a project budget. There just isn't
enough proof out there. And as the community is still struggling with
how to build WPF applications ...

http://blogs.msdn.com/avip/archive/2009/11/14/mvvm-this-might-hurt-a-little.aspx

it is harder still to claim reduced development costs. Not every
developer is a disciple!

I don't think it is a misconception that all companies want browser
based applications. I think it is more common that companies want
browser based applications but don't know why!


Regards,
Colin E.

On Nov 20, 10:37 am, "Peter O'Hanlon" <pete.ohan...@gmail.com> wrote:
> Colin - much as I respect you, and I do you know, what WPF offers is much
> more than a pretty interface. 1st class databinding means that it's easier
> to develop data based applications than WinForms/MFC/pick your desktop
> platform here. This ease of development, lowers the development time and,
> hence, decreases the time to achieve the ROI. As a business owner, being
> able to deliver critical systems in less time, and at lower cost than the
> competition, means that we are getting more bidding opportunities because of
> it.
>
> There's a common misconception that all companies want browser based
> applications. In the environment we tend to operate in, browser apps are
> distinctly frowned upon, so WPF will long have a place with our clients.
>

> On Fri, Nov 20, 2009 at 10:07 AM, Colin Eberhardt <colin.eberha...@gmail.com

[Peter O'Hanlon]

As far as the cost benefit goes, it's easier for me as a technical business owner to justify. The lower cost only comes once you have a team that is comfortable with WPF - but the same can be said of SL as well, so it doesn't have to be a clinching argument.

--
Peter O'Hanlon

[Daniel Vaughan]

As far as WPF and Silverlight convergence goes, there are some
fundamental differences between the way the Desktop and Silverlight
CLRs do things. For example, as we know, synchronous web service calls
don't work from the UI thread in Silverlight. This being the case,
compromises would need to be made with cross browser compatibility in
order to bring some features that the desktop CLR has to Silverlight.

I was frankly flabbergasted by Scott's announcement about the
redistributable size of the Desktop .NET framework 4.0 compared with
3.5. 3.5 was 197MB, while the full 32bit redistributable is now only
38MB. At the moment we are looking at Silverlight 4 beta for Windows
(7.63MB) or for Mac (15.4MB) (http://arstechnica.com/microsoft/news/
2009/11/silverlight-4-beta-arrives-for-developers.ars)

From a technical standpoint, at some point it would make sense to have
a unification. But from a commercial perspective, I dare say there are
business reasons that would prohibit such a convergence. To me it
would make business sense for Microsoft to keep the CLRs separate as
they are, with limited interoperability. But maybe I am crossing a
line here by speculating about such things.

[David Anson]

Not getting into this argument [ :) ], but a quick clarification about the size of the SL4 runtime I shared with someone else:
http://twitter.com/DavidAns/status/5836667844

[Shawn Wildermuth]

Yeah, the 7.5mb is the developer version (with good error msgs), the client
version will be ~5mb

[Daniel Vaughan]

No arguments here! Only friendly chit chat. :)

Thanks for the clarification David. 5MB isn't such a stretch from 31MB
(Client Profile) these days though, wouldn't you say? Or maybe I am
wrong.

[David Anson]

I agree that the new lean/mean client profile is a big win for WPF deployment. I also think the Silverlight install experience is quick and seamless due to its size and its nature.

As a parent, I try not to pick favorites. This discussion here is kind of similar... ;)

[Eric Burke]

Just to chime in after PDC:

We had a brown-bag with some of the WPF team [John Gossman, Rob Relyea, Mike Hillberg, Ian Ellison-Taylor (the GM of WPF and SL), ...]. Naturally, this question came up.

Ian answered:

+ VS10 is built using WPF, which means that MSFT is committed to WPF for at least the next N (he said 10) years.

[I sat in Paul Harrington's talk on how they build VS10 off of VS9 while switching to WPF. For anyone who has done a large-scale app in WPF, they are solving a ton of interesting problems. They are also driving the framework based on their needs. Clearly, MSFT is serious about VS, so that means they are serious about WPF.

What Paul also said is that there are a lot of eyes on the VS10 project internally. Office and other large apps are all looking to VS10 to blaze the trail; if they are successful, other projects will likely move to use WPF.

So hopefully the question of "if WPF is so special, why isn't MSFT building more apps using it?" will be moot. ;)]

+ Silverlight is a brand. WPF is a technology.

This IMO is the most important one from an external standpoint. The reason project managers and other non-tech folks know about SL is because MSFT markets the heck out of it. It's an end-user play. They want adoption, just like Flash. They need users to say, "Sure, I'll go download that".

MSFT will never market the heck out of WPF. Hell, many windows devs I know are like, "WP-what?" whenever I say it. It's aimed at developers. Project managers and the like will never say, "Oh man, we need to build that in WPF." because they don't know, nor should they care.

Microsoft wants SL to become the cross-platform application platform of choice. They recognize that we live in a RIA world now, but there's also a need for desktop support without going full-on native client apps. SL4 and it's out-of-browser stuff aims squarely at Air 2.0. In-browser it's aimed at Flash. And the hope is that if they get to the point of API compatibility (which is getting much closer and is often solved using the WPF or SL toolkits in conjunction with the platform), then breaking out to a full native client will be an easier transition since you can share XAML and resources and often backend code. And if you need Windows only and/or need some serious low-level stuff like P/Invoke to legacy code, you use WPF. (SL4 can talk to legacy code if you have a COM wrapper with IDispatch.)

It will be interesting to me to see where the fight ends up between SL vs. Flash, SL vs. Air 2.0 vs. other cross-platform shells such as Titanium.

The one non-story surrounding SL is mobile. They seemingly have nothing, whereas things like Titanium run on mobile browsers. I've heard rumors of SL support on WM7 but there's been nothing official and it's a huge sore spot right now. Anyone know anything about that?

[Daniel Vaughan]

Thanks for the insight Eric. Very interesting.

[Justin Angel]

Hi Folks,

I'd like to chime back in on the original discussion here: Silverlight
versus WPF.

Emphasis should be placed that this is indeed a situation of sibling
rivalry.
When developers click "File --> New Project" a choice between WPF and
Silverlight is forced upon them.
That choice and many others determine which is the successful
framework.

How is the success of platform/framework measured?
Well, there's a lot of metrics associated with that question:
Installation numbers, download statistics, number of apps built,
community engagement, and various other quantifiable objectives.
The core success of most commodities in this new information economy
is attention, in this case in the form of *adoption*.

Check any of those adoption stats you'd like and you'll find that
Silverlight passes WPF by a factor of at least 2:1.
google trends, number of forum posts, number of control group apps
built, everything.

Silverlight is obviously a leaner "WPF Lessons Learned" framework.
100% of the WPFness, with 10% the calories.
2 years ago I'm quoted in saying "In 5 years we'll call WPF
'Silverlight Pro'".
Personally, I think I was wrong.

WPF is going to die a painful, excruciating and prolonged death
following the footsteps of most microsoft platforms/frameworks.
How many times has anyone here heard Microsoft officially declare
"Winforms is dead"? "Webservices are dead"? "ASP 3 Is dead"?
But yet we all know they are.

Just compare the unattrective bug fixes in WPF4 (Woo, better font
rendering and an improved XAML parser) to the sexy Silverlight 4
featureset.

When I look at the Silverliht 4 feature set all I hear is "game-set-
match" for Silverlight vs. WPF.
With SL4 elevated privileges which enable COM access, that's a carte
blanche cheque for Silverlight apps to do whatever they want to.

From the moment SL4 got COM access in elevated OOB, WPF became the
niche platform.
Common execuses to use WPF in the next couple of years will be:
"Integrate C++ code to our apps", "a horrible 3D framework", "Full
desktop .Net access" and other niche excuses.
If you look at Platform/framework as biological evolution, then WPF is
a Neanderthal. And Silverlight is homosapiens. Sure, WPF was here
first and Neanderthals have bigger brains, but WPF will die out just
the same.

After this somewhat long winded post, I'd like to call out that I have
yet to formulate an opinion on "Silverlight 4 vs. WPF".
Given where we are with Silverlight 4 (being only 4 months old), all I
have are preliminary thoughts which I've shared with you.
When developers select platforms for greenfield apps in the upcoming
months, that's where we'll really see this issue play out.

Does anyone have any thoughts on what the Silverlight & WPF playing
field is going to look like in 2-3 years?

-- Justin

[Bill Kempf]

"Just compare the unattrective bug fixes in WPF4 (Woo, better font
rendering and an improved XAML parser) to the sexy Silverlight 4
featureset."

SL4 has been given a lot more "love" than WPF4, but that "love" adds
very little that doesn't already exist in WPF3(.5). So this argument
is at least a tad off the mark. The day SL is used to create an
application like Visual Studio or Office is the day I'll say that it
has any chance of "killing" WPF in the same manner that WPF killed
WinForms (which, honestly, it didn't).

I'm still disturbed by the movement towards web applications. I would
have much preferred to see Microsoft put more emphasis on a cross
platform desktop CLR and a nicer click once deployment model. With SL
OOB, the compatibility between the frameworks and the slow push to
feature parity, maybe that's where we'll eventually wind up anyway,
just down a different path from what I would have preferred. Until
then, SL has no chance of "killing" WPF. Unfortunately, it seems like
it might "smother" it, however. With all of the development focus on
SL, it does feel like WPF isn't getting the attention some of us would
like. That may not be a fair impression, since some of the new WPF
goodness (especially in the tooling) certainly would have taken
significant development resources that may really be on par with SL4.
It just doesn't feel that way :(.

--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

War is peace. Freedom is slavery. Bugs are features.

[Mike Brown]

Silverlight has been playing catch-up with WPF. A lot of the features that are a big deal on Silverlight were there V1 for WPF. I think the apparent "slow-down" of WPF has been due to the fact that it was so powerful to begin with. If you think of the features announced for Silverlight 4, most of them were in some way related to giving the developer more access to the machine (that said, I would love to have a simplified webcam/microphone API in WPF). In the meantime, the WPF team has been focused on the LOB story (which is what people were clamoring for).

 

I will tell you this however. This does tremendously impact my decision matrix going forward. I'm not saying that Silverlight will be the default choice for "New Project..." but it has a lot more points in its favor than it had before.

[Jeremiah Morrill]

Justin,

I can only infer from your post that you assume that these two technologies should mean the same thing to all people.  My opinion is that it certainly is not.  While citing adoption rates may be a great way to measure success of the platform, it says nothing when comparing it to WPF.  Consider the developers moving from Flash/Flex, or the huge number of web developers (ASP.NET, PHP, etc) already out there picking up SL as a way to extend or evolve their web centric applications.  These are the folks that may never consider even making a desktop application in the first place.

I can see how you would see COM interop in SL 4 as another nail in the coffin for WPF, but if you take a close look, you will see something very glaring.  SL4 ONLY supports COM automation.  What does that mean?  It means we can integrate with things like Office.  Keep in mind most of Windows COM does NOT support automation.  We could create a COM that does support IDispatch to wrap what we need, but doesn't requiring the end user to download and install something else totally break the SL deployment model?  In my opinion, SL COM interop was primarily made to help make office interop easier.  If not, they'd give us full COM interop, not something neutered.

Having integration of technologies is NOT an "excuse".  It can be a requirement for actually making something WORK.  I have customers that would not even be able to ship a product (ie stay in business) because the need to talk to a device driver, or managed code is too slow for realtime processing....or they needed to integrate <some_tech> into their application.  I'm glad SL covers 100% of all your development needs, just because you don't need it, does not mean it's a "niche".  Just because most applications are web apps, doesn't mean the desktop is dead.  If you think so maybe you should be running Chrome OS.

One thing I can buy, as Josh put it, is looking back (time frame arguable) and seeing WPF as a "proof of concept".  I can see the two technologies becoming more related; merged.  I could even see WPF being rebranded as Silverlight and maybe even using the milcore (IIRC, even DWM uses milcore) in OOB on Windows.

All I'm saying is the [software] world is becoming increasingly heterogeneous.  The keyword of today and tomorrow is "interoperability", not murder-death-kill.

[Justin Angel]

"the day SL is used to create an application like Visual Studio or Office is

the day I'll say that it has any chance of "killing" WPF"

Office web apps are already being developed using Silverlight.

http://blogs.msdn.com/officewebapps/archive/2009/08/05/9858563.aspx
http://www.off14.com/microsoft-office-14-for-the-web/

Hi look, it's Excel in the browser using Silverlight. Amazing.

Microsoft doesn't kill platforms by executing developers who use them, it
just stops developing them.
Again, Winforms, ASP3 & Webservices are prime examples of dead Microsoft
technologies.
If you're feeling the lack of WPF love at the Microsoft side, guess what
that means.

-- Justin
(This is all purely speculation, If I had any first hand information on a
nefarious Microsoft plan to kill WPF I'd keep it to myself.)

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Bill Kempf
Sent: November-20-09 1:35 PM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: Future of WPF/Silverlight

[John Gossman]

I admit to understanding some but not all of the angst about WPF vs Silverlight.  I apologize for the incompatibilities which have been forced upon us by engineering expediencies, but our goal is to have the same set of APIs that work for deep Windows development and Web development.  Folks don't seem to have so much angst over Windows and Windows Mobile or over doing Windows NT development versus Windows 9x.  Would you all feel Silverlight was killing WPF if we had stuck with the name WPF/e? 

 

As Mark points out, one reason WPF development seems slower is it is already way more complete.  With Silverlight we started later and frankly the competition has gotten tougher, so we've had to really hit the accelerator.  You are also seeing some interesting scheduling things.  WPF 3.5SP1 was actually a pretty major release and it cut into WPF 4 development, much of which was taken up with engineering goodness things we had to do like replace WPF's original text stack with the new DWrite stack from Win7 and support Visual Studio development. 

 

Our goal is to make you not have to choose.  Source compatibility is already pretty good especially now that VSM is officially in WPF.  With .NET 4 we are taking the first step towards binary compatibility, leading towards a more WinNT/Win95 world where it should be relatively easy to develop for both implementations at the same time. 

 

Finally, as several have pointed out...choosing between the two is mostly a business decision and in practice that is usually not that hard.  Most customers I talk to know whether they have to be cross-platform or not and whether they need heavy access to Windows desktop features or not.  As we move to make it easier to develop for both platforms the blurry middle area will inevitably grow, but the two products are not on a collision path...they are on a convergence path.

[Eric Burke]

Also, don't forget that SL OOB is competing with Air 2.0.  Read this post about the Air feature set.  Many overlaps.  http://www.adobe.com/devnet/logged_in/rchristensen_air_2.html

Another data point: Surface is WPF as well.  Not sure if it will ever migrate to SL -- my guess is that it can't because of the h/w stack and the need to get at the metal.  So there are a number of cases where WPF is necessary and/or useful.  If the API compat continues to increase, then choosing one over the other is sort of a moot point if all you need to do is flip a switch.

It might be that SL has the majority of the uses in the long run, but it's not all that different than using, say, a high-level 3D toolkit for the majority of your graphics apps, but then switching over to use Win32+OpenGL when you need the hardcore performance.  The toolkit doesn't kill the OpenGL solution at all, but it does provide a solution that more people will use.

From: Mike Brown <mbro...@gmail.com>
To: wpf-di...@googlegroups.com
Sent: Fri, November 20, 2009 4:59:46 PM
Subject: [WPF Disciples] Re: Future of WPF/Silverlight

[Bill Kempf]

1. Web "office" apps, no matter the hype, or even the real
usefullness, aren't Office. Not yet, anyway. SL would help it to get
closer, but it still wouldn't really compete. For one, to really
compete, the "web app" would be so large that users wouldn't wait
around for the download to complete.

2. WPF has appeared to slow (though I'm not convinced yet that that's
anything more than an outsider's mistaken perception), but has far
from been abandoned.

--

[Paul Stovell]

Hi John,

I think part of the fear is that while people know their skills are transferable between products, they know that codebases don't transfer so easily, and no one wants to develop for a platform that might be the next Foxpro. It's also not just the fear of dropping a technology in favor of another - that seldom happens - but having one flourish with lots of nice new features and attention while the other languishes forever.

If I'm going to use WPF, I want to use the nice WPF/.NET -only features. But if I think I'll have to switch my product to Silverlight in 3 years because Microsoft's WPF efforts have stalled, maybe I'll just use the Silverlight subset and take twice as long to build it. So that's a real risk because it costs time and money, and Microsoft's customers and partners are making those decisions every day. We hear statements like 'Microsoft is serious about WPF', but the that's not enough to convince people. So we read the tea-leaves of PDC and Mix announcements and to try to guess what Microsoft's intentions 5 years from now will be.

Microsoft talk a lot about WPF/Silverlight being a continuum. Learning wise it is, which is great, but when you sit down to write an application, even if Silverlight followed WPF 100%, it absolutely is not - it's one or the other, there is no middle ground. I bet they can't switch Visual Studio 2010 from WPF to Silverlight in a week, heck, not even a year. Where's the continuum there? I actually wish the teams at Microsoft understood this better and stopped telling us not to be worried since they both use XAML therefore there's no costs.

Folks don't have angst over Windows vs Windows Mobile because they are pretty confident in the future of the two - my business won't go bankrupt because Microsoft canned Windows and told everyone to buy a phone instead of a PC. They can make a choice and be confident three years from now that it won't bite them in the butt. Personally I don't feel that way about WPF or Silverlight right now :(

Paul

--
Paul Stovell

[Laurent Bugnion]

Loving John's reply. Having the chance to work for a firm that is deeply involved with both technologies and with devs and designers who switch from WPF to SL depending on the projects they work on, I don't quite see what's all the fuss is about. As i said often, the story is one of convergence, not of competition. I recently had the chance to talk to a few prospective customers who are early in the process of moving from MFC or WinForms or ASP or ASP.NET (and in one case, from Java applets) to WPF or Silverlight. In all cases, which framework was to be used was very clear due to the requirements.

One thing that needs to be better is the ClickOnce story (both the experience and the marketing should be improved) because i recently had 2 cases where the devs wanted to do SL when WPF+ClickOnce was obviously better, but they did not know about it (both had never heard of ClickOnce and were giddy when i demoed it to them). Other than that, and apart from the fact that I still think it would be cool if WPF had a better name and a shiny logo, i couldn't be happier about the recent developments in WPF/SL and about the convergence which is happening.

Cheers,
Laurent
--
Sent from mobile

-original message-
Subject: [WPF Disciples] Re: Future of WPF/Silverlight

[Karl Shifflett]

Laurent thank you very much for a clear, no axe-to-grid approach to the two coolest technologies!

I like to use the time honored approach to technology, "select the correct tool for the job."

FYI: Silverlight is not a Golden Hammer, neither is WPF or any other technology.

Cheers,

kdawg

[Corrado Cavalli]

I can only agree.
My position here is: who cares?
I'd be worried if I'd had to choose between Adobe technologies vs Silverlight/WPF but since they're both on the same side (and 80% identical) I recommend the solution that fits best for customer's scenario.
I've many customers who needs to interact with local hardware, others that must install the application on machines that have no network connection.
Let's face it, it's quite obvious that in a few years we'll have a single technology but I don't see it as a problem, finally is just a bunch on XAML :-)
There's an area that's totally uncovered by both SL/WPF that could boost the market: Embedded and Mobile (ok, CE6 R3 has something but it's a C++ thing...) I keep getting asked: "When we'll be able to use SL/WPF/Whatever on Embedded?"
Those of you who did mobile/embedded development know how hard is to get an appealing look and feel.

Please give us SL/WPF for embedded-mobile development.

.C

[Peter O'Hanlon]

Interesting thread. One of the big wows of recent years has been Touch applications. With WPF supporting touch as a first class feature, this is something that certain industry sectors are getting interested in. You know that I deal with security and defence companies - multitouch is something that really, really appeals to them. AFAIK, SL doesn't support touch (I could be wrong on this, I stand to be corrected), so it's not a natural fit for this. As more hardware comes out touch enabled, WPF will become the development environment of choice for it.

--
Peter O'Hanlon

[Laurent Bugnion, GalaSoft]

Hey Pete,

 

Actually Silverlight 3 supports multitouch.

 

Cheers,

Laurent

[Bill Kempf]

See, part of the problem is we talk about a convergence, but that's
not been the observations. For example, there have been a lot of
controls developed for SL, such as the Accordion, that haven't been
developed for WPF. SL gets more attention for validation, than does
WPF. And so forth. For most of us, this isn't such a big deal, but for
many others, they "read the tea leaves" and see something entirely
different.

Then there's wording chosen during the PDC. "The future is
Silverlight" might have meant one thing to the presenter, but the
message heard by the audience is often something else.

--

[Peter O'Hanlon]

Cheers Laurent - I wasn't aware of that.

--
Peter O'Hanlon

[Shawn Wildermuth]

And there are some good gesture Behaviors in http://expressionblend.codeplex.com that will help

[David Anson]

Bill (and everyone else),

You may know that I own the Data Visualization part of the Silverlight Toolkit and also that I did the work to get it added to the WPF Toolkit for their most recent (June) release. This had always been my goal, and it was nice to get it realized.

What's particularly relevant to your comments below is that I've been talking with the WPF Toolkit folks recently about migrating more of the rest of the Silverlight Toolkit over to the WPF Toolkit. As before, it'll be just little 'ol me doing the work and pretty much doing it in my free time, but I'm hopeful that I can migrate ~3-5 controls for the next WPF Toolkit release.

If folks here have opinions about which ones to focus on, I'll take that under advisement. :) Bill seems to have already cast a vote for Accordion. Another that seems interesting is the SDK's AutoCompleteBox. But beyond that, I haven't done much thinking - I'd love to hear if there are particular controls you folks think belong in WPF.

Thanks for your feedback!

[Mark Smith]

David -- I'm sure others will offer as well, but I'd be happy to help with that effort in my spare time as well - I've already got several controls ported that I found useful and I could send some of that code to you if it would help.

mark

[David Anson]

Mark, thanks a lot for your very generous offer! I truly, sincerely mean that. Unfortunately... I may not be able to take you up on it. :( Let me explain why so there are no hurt feelings.

Before I was involved with Silverlight, I worked on the AJAX Control Toolkit which was also open source. One of the neat things we did was accept community contributions. In many ways, this was a great thing: the community benefitted from a richer set of controls, the contributors benefitted by sharing their work with others in a high profile project, we benefitted by having more resources, etc.. However, the involvement of non-Microsoft people had an unintended consequence: certain internal and external teams were reluctant to take a dependency on our work because of the fear that one of the external contributors might have inadvertently introduced some third-party intellectual property into the codebase. (And if you're up on your tech news, you may know of a situation just last week where this very thing seems to have happened to another team.) Though I'm confident nobody we worked with would have done (or did) this, the simple possibility of it created a big hurdle for partner teams and in some cases they were unable to make use of the Toolkit despite a strong desire to.

So even though third-party contributions did a lot of good, this particular problem was big enough that we made a specific decision with the Silverlight Toolkit NOT to accept third-party contributions. To be clear, the Silverlight Toolkit is still full-on open-source Ms-PL (OSI approved), but we don't allow "take-backs". Which is a shame in some ways, but I still believe it's the right call because the story for customers is super-simple: this is all Microsoft IP, here's the Ms-PL license, there you go, have a blast. :) Consequently, internal and external teams have been able to take a dependency on the Silverlight Toolkit without a hurdle - and many of them have.

All that said, I don't *know* the policy of the WPF Toolkit team. And I'll ask! But I doubt that the situation is much different for them than us. In fact, because we've now seen that WPF Toolkit controls can migrate into the .NET Framework itself (as most of the WPF Toolkit controls have done for .NET 4), I'd guess that they've got plenty of reasons to be strict, too.

Long story short: I appreciate the help, I wish I could take advantage of it, I will if I can, but I expect that I can't.

I hope I've done an okay job explaining things here. If you've got any specific concerns, please share them with me - either publically or privately.

Thanks.

PS - I am not a lawyer; this is just my perspective on why things are the way they are. :)

[Mark Smith]

No hurt feelings at all -- I understand the position completely, better to be safe than sorry!

Thanks,
mark

[Bill Kempf]

Well, I have my own Accordion at this point ;). Also, I hope that my
post wasn't entirely misunderstood. I understand development
scheduling and can guess why things are the way they are... but the
point is, it's little things like this that give the impression that
WPF is stagnating while SL is what's important to MS. I'm saying that
MS is developing a PR problem. This needs to be solved like a PR
problem, and not through any real change to how SL/WPF are being
developed.

That said, I'm excited to hear that work is being done to bring these
controls to WPF! :)

[John Gossman]

And btw, the position of the WPF team is that we can't take contributions.  I had to tell several customers last week that we did not take source contributions from outside MSFT because these folks were of the impression that because we had released the source we did and they don't use any open source software.  It really is an interesting world: groups that *only* use open source software and other groups that *never* use open source. 

[Tamir Khason]

> Comparing the two lists I can't help feeling that WPF isn't getting the

> love. The WPF features seem small (effort-wise) when compared to Silverlight
> features like printing support. That said maybe the WPF features were very
> time consuming to implement and they just appear small from the outside
> because they did such a good job of making it look easy.

I am not MVP anymore, so I'll be unable to ask my favorite question
about the future of WPF vs. Silverlight again (for those who remember
this question, related to the future of it). But, frankly, today as
one who should answer old customers to the same question "why you
advice to use WPF? We invest a year in learning, another year in
developing and now we realize that our app looks much shiny, but stuck
and no one all over the world (and in Microsoft) can explain us why we
could not do it in Silverlight by investing a quarter to time and
money and get better and much responsive app" again and again, I'd
answer: "I still believe in WPF (even as one who completely rewrote
non-responsive rendering and data binding for my own app, and one
who's advices were incorporated into this skimp update of WPF 4.0) and
think that now you learned a lot and know how to do things yourself".
This statement is very similar to how experienced core C++ programmer
take guys learned Java (or C#) in "another have your new profession
within a month" training for this team.
This statement is very similar to my another favorite question, a
asked Anders Hejlsberg: "Why you want to turn .NET into Javascript?".
The right answer to those and all other similar questions is: "'cos it
demands" and unfortunately we have nothing to do with this, so let's
try to learn to live with

--
Tamir http://khason.net/

[John Gossman]

I would like to focus the WPF team's efforts on fixing things only the WPF team can fix.  It is hard though when external perception does seem to be so different from internal.  For example, blurry text was one of the number one complaints about WPF and a complete blocker for some customers (like VS).  Moving to DWrite and fixing the problem was a huge effort, many times larger than adding basic printing to Silverlight or (not to pick on Bill) 100x larger than adding an Accordian control (which can be done by a 3rd party or easily ported from the Silverlight toolkit).  Frankly I don't think WPF needs a lot of more features.  I think we need to do more performance work, continue to improve interop with HWNDs, DX and HTML and polish up the more complex APIs (I'd like to simplify DependencyProperty syntax for example).  However, this thread leads me to believe we need to write more controls...which will take away from the fundamentals again.

[Bill Kempf]

The point I've been trying to make here, is that there's a PR problem.
Just creating controls for WPF may not fix that PR problem, though it
doesn't make a lot of sense to create a control that exists in SL but
not provide a counterpart for WPF. That sends a message that SL is
being actively developed for, while WPF is not. Again, I REALLY want
to stress that I understand this message is NOT accurate. I agree with
you, John, I'd rather see the bigger things done in WPF, rather than
the simple things like adding an Accordion. That doesn't change the PR
issue, though, as most people just don't see/understand this. I don't
have a complete answer here, but some suggestions:

1. Don't add something to SL that's missing from WPF unless you also
add it to WPF.
2. Be careful with statements like "The future is Silverlight." in keynotes ;).
3. Find something that WPF can innovate (SL has had the VSM and
Behaviors... both of which exist in WPF, but the story given is always
that these were SL innovations). IOW, you just need one significant
and highly visible piece of new tech coming from WPF to turn around
perceptions.

Of course, maybe fixing the PR problem isn't that important. WPF isn't
abandoned, isn't really getting less attention and is extremely
important to Microsoft. If people aren't seeing that now, does it
really matter (especially to Microsoft, since WPF isn't something that
adds directly to the bottom line)?

--

[Peter O'Hanlon]

John

 

I'd have to agree, and disagree, with you on this. I'm delighted that the WPF team is going to focus on the things that only they can fix, and this is much more important to me than adding custom controls. I'd rather that the WPF team concentrated on the core functionality, and let the community help add the "missing" controls. Perhaps MS needs to relax it's, only MS can contribute the code to the codebase attitude, for these controls and then authorised (read trusted here) developers could contribute to adding external functionality.

 

Pete

--
Peter O'Hanlon

[Josh Smith]

I agree that fixing/improving core WPF features is far more important than adding whiz bang features like Accordion controls.  However, WPF needs a DateTimePicker control built into the framework.  Does WPF 4 have one?  If not, how on Earth has this fundamental UI control not made it into the proper framework yet?  It's difficult to convince someone that WPF is a good choice for LOB apps when you have to mention that it doesn't have a DateTimePicker.

Josh

[Sacha Barber]

Yeah I agree with Josh who heartedly on that one. Even the one in the WPFToolkit only just became good enough when the VSM bug got fixed which wasn't that long ago.

--
Sacha Barber
sacha....@gmail.com

[Mark Smith]

The DatePicker control (from the toolkit) appears to be in WPF4 now, as is the Calendar and DataGrid controls - all good things for LOB development.  

Personally, I think the main observation here is that Silverlight seems to get these controls first and WPF appears to be an afterthought.  The fact that Silverlight had a production ready DataGrid almost 2 years before it showed up in the formal WPF framework certainly seems to make that point clear.  Don't get me wrong - I *love* the work the WPF team has done for 4.0 -- the new text rendering and composition features are awesome and I'm all over VSM-- especially the new GotoElementState which is great, but Siverlight definitely gets more attention and is evolving at a much faster rate - consider that it's already at 4.0 in what, 2 years?  It's almost evolving faster than I can keep up with it's feature set!

As much as was done with WPF 4 + SL4, I'd love to see more convergence between the two - I want better validation support and a real WebBrowser control in WPF (not a wrapper over IE that causes airspace issues).  I find Preview events to be very useful in WPF:  creating a drag/drop tab control is far harder in Silverlight without them because it requires derivation to hook into the mouse activity of the TabItem.  I'd love to see complete control parity between them so moving between the two platforms isn't as hard - why is there now a VideoBrush and HTMLBrush in Silverlight instead of just going the extra mile and providing a VisualBrush? Where's the PlaneProjection in WPF4?  I understand there are technical issues to solve, limited resources and you are in a highly competitive space, but it seems like these quicker, shorter-term solutions directly impact the cross-feature goal that I think you want to achieve.  It's certainly sending a mixed message to developers of where you are going and what is important, or maybe it's just me :-)

mark

[Bill Kempf]

Obviously, it's not just you :).

--

[Daniel Vaughan]

Yes indeed, convergence starting perhaps with the most common
controls.
I realize that Silverlight gets some things first. A couple notable
exceptions are however the menu and toolbar controls. I’m not too
fussed about the more niche controls. While they are nice to have, one
can usually resort to third party controls for those. But for the
fundamentals, I’d prefer to be able to draw from the core framework.

If someone says, “but Daniel, haven’t you seen the Silverlight 4 beta
has a new menu control!” I’ll be a happy man. (I have looked, but I’m
prone to miss stuff like that.)

On Nov 23, 6:23 pm, Mark Smith <mark.jul...@gmail.com> wrote:
> The DatePicker control (from the toolkit) appears to be in WPF4 now, as is the Calendar and DataGrid controls - all good things for LOB development.  
>
> Personally, I think the main observation here is that Silverlight seems to get these controls first and WPF appears to be an afterthought.  The fact that Silverlight had a production ready DataGrid almost 2 years before it showed up in the formal WPF framework certainly seems to make that point clear.  Don't get me wrong - I *love* the work the WPF team has done for 4.0 -- the new text rendering and composition features are awesome and I'm all over VSM-- especially the new GotoElementState which is great, but Siverlight definitely gets more attention and is evolving at a much faster rate - consider that it's already at 4.0 in what, 2 years?  It's almost evolving faster than I can keep up with it's feature set!
>
> As much as was done with WPF 4 + SL4, I'd love to see more convergence between the two - I want better validation support and a real WebBrowser control in WPF (not a wrapper over IE that causes airspace issues).  I find Preview events to be very useful in WPF:  creating a drag/drop tab control is far harder in Silverlight without them because it requires derivation to hook into the mouse activity of the TabItem.  I'd love to see complete control parity between them so moving between the two platforms isn't as hard - why is there now a VideoBrush and HTMLBrush in Silverlight instead of just going the extra mile and providing a VisualBrush? Where's the PlaneProjection in WPF4?  I understand there are technical issues to solve, limited resources and you are in a highly competitive space, but it seems like these quicker, shorter-term solutions directly impact the cross-feature goal that I think you want to achieve.  It's certainly sending a mixed message to developers of where you are going and what is important, or maybe it's just me :-)
>
> mark
>
> On Nov 23, 2009, at 10:49 AM, Sacha Barber wrote:
>
> > Yeah I agree with Josh who heartedly on that one. Even the one in the WPFToolkit only just became good enough when the VSM bug got fixed which wasn't that long ago.
>

> > On Mon, Nov 23, 2009 at 4:29 PM, Josh Smith <flappleja...@gmail.com> wrote:
> > I agree that fixing/improving core WPF features is far more important than adding whiz bang features like Accordion controls.  However, WPF needs a DateTimePicker control built into the framework.  Does WPF 4 have one?  If not, how on Earth has this fundamental UI control not made it into the proper framework yet?  It's difficult to convince someone that WPF is a good choice for LOB apps when you have to mention that it doesn't have a DateTimePicker.
>
> > Josh
>

> > On Mon, Nov 23, 2009 at 4:56 AM, Peter O'Hanlon <pete.ohan...@gmail.com> wrote:
> > John
>
> > I'd have to agree, and disagree, with you on this. I'm delighted that the WPF team is going to focus on the things that only they can fix, and this is much more important to me than adding custom controls. I'd rather that the WPF team concentrated on the core functionality, and let the community help add the "missing" controls. Perhaps MS needs to relax it's, only MS can contribute the code to the codebase attitude, for these controls and then authorised (read trusted here) developers could contribute to adding external functionality.
>
> > Pete
>

> > Tamirhttp://khason.net/

>
> > --
> > Peter O'Hanlon
>
> > --
> > Sacha Barber

> > sacha.bar...@gmail.com
>
>

[David Anson]

"But Daniel, my goal for the next release of the SL4 Toolkit is to provide a ContextMenu for right-click support that's not quite a full-on Menu control, but something like it and I'd surely try to do so in a WPF-compat way perhaps by starting from the following implementation from another MS guy which isn't quite what you wanted to hear but maybe it's close enough that you'll be a kind-of-happy man for now."

http://www.jebishop.com/2009/11/18/implementing-a-contextmenu-in-silverlight-4-beta/

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Daniel Vaughan
Sent: Monday, November 23, 2009 10:07 AM
To: WPF Disciples
Subject: [WPF Disciples] Re: Future of WPF/Silverlight

[Daniel Vaughan]

Haha yes, that’s way cool David, but not quite what I’m after. :)
You see, in the project that I’m thinking of, I am trying to provide
for both WPF and Silverlight. It means diverging in order to support
the lack of a Silverlight menu and toolbar.

On Nov 23, 7:36 pm, David Anson <david...@microsoft.com> wrote:
> "But Daniel, my goal for the next release of the SL4 Toolkit is to provide a ContextMenu for right-click support that's not quite a full-on Menu control, but something like it and I'd surely try to do so in a WPF-compat way perhaps by starting from the following implementation from another MS guy which isn't quite what you wanted to hear but maybe it's close enough that you'll be a kind-of-happy man for now."
>

> http://www.jebishop.com/2009/11/18/implementing-a-contextmenu-in-silv...

[Paul Stovell]

Hi John,

Text rendering was an issue for my customers too so I'm glad that was solved. From the outside printing looks a lot harder, but if you say text was more work then I'm very impressed.

I'd love to see more focus on performance and fundamentals too. It's annoying that the Silverlight team spent so much effort on datagrids and other things third parties could have built, and so little effort on making the framework extensible and more friendly for those third parties (features like DP inheritance). There is a lot of work that could be done around WPF's navigation feature for example to make it more compelling - but the classes and hooks we need are all internal so we can do nothing. So by all means please do the things we can't before the things we can. :) 

Paul 

[Jeremiah Morrill]

I'd like to add that the new features coming in WPF4 are phenomenal.  On the perf side, BitmapCache is absolutely nothing short of amazing.  Yeah it's been in SL since 3.0, but the performance gains are a totally different magnitude.  BitmapCache on my SL took my CPU from 80% down to ~35% in some animated scenarios (gaining FPS of course).  BitmapCache has taken some my WPF scenarios from ~5FPS -> 60 FPS and barley any CPU at all!  Pavan, your ElementFlow will FLY!  As far as I can tell, this fixes almost all performance issues I ever had with WPF graphics (in general).

>> continue to improve interop with HWNDs, DX and HTML

These interop scenarios are VERY important.  To be able to host an hWnd (and HTML) w/o airspace issues, to be able to render WPF UI in a DX scene...increases WPF utility ten fold (that's a rough estimation)!  I have no desire to use XNA to make games, but I do see it as a superior graphics framework to spruce up my WPF application.  I have no desire to make a GDI based ActiveX/Winforms controls, but I do have tons of 3rd party stuff I have to use and airspace restrictions really mess up my flow.  I can see a DX games developer hating to have to reinvent a button, so why not use WPF to directly render in the game scene?  I'm very glad to hear that these scenarios are, at the very least, being thought about (unless I misunderstood the context of 'improved interop').  

Sorta relating to interop...I'm working on a D3D10,11, D2D interop lib for WPF (D3D10->9Ex is faaassst).  Proof of concept almost done.  Anyone, hit me up if you'd like to help or had any input on what you'd like to see.

-Jer

[Walt Ritscher]

Miguel de Icaza calls Silverlight 4 revolutionary.

 

“There are many other great features in Silverlight 4, but none as important as Silverlight becoming a universal runtime for the CLR. This is a revolution.”

http://tirania.org/blog/archive/2009/Nov-23.html

 

Walt Ritscher

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Jeremiah Morrill
Sent: Monday, November 23, 2009 4:00 PM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: Future of WPF/Silverlight

 

I'd like to add that the new features coming in WPF4 are phenomenal.  On the perf side, BitmapCache is absolutely nothing short of amazing.  Yeah it's been in SL since 3.0, but the performance gains are a totally different magnitude.  BitmapCache on my SL took my CPU from 80% down to ~35% in some animated scenarios (gaining FPS of course).  BitmapCache has taken some my WPF scenarios from ~5FPS -> 60 FPS and barley any CPU at all!  Pavan, your ElementFlow will FLY!  As far as I can tell, this fixes almost all performance issues I ever had with WPF graphics (in general).

[Jaime Rodriguez]

This has been a great thread.  Lots of Microsoft people are getting great insights, learning from it, and discussing it internally. 

 

Here is my insider  view:

Most of us are very excited –maybe as much as Miguel  despite our lack of eloquence – about the future of .NET XAML apps.. (yes, to some of us Silverlight is .NET code)

 

Back to the original question on future of WPF/Silverlight, I think it is easier if you answer it.  How many of you  could meet your current products requirements with Silverlight 4?    

[Note, I expect answer to be “some but not all , and percentage is growing, but it won’t reach 100% for a few years” ]

 

A few points that I read from the thread and would like to comment on:  

·         Attention != Adoption.   Look at Sharepoint, this platform is growing a lot (quietly)

o   There was a 2:1 number quoted on SL:WPF ratio.    I assume this was attention.  I do not use that metric,  I focus on:

§  There is more production WPF applications today than there is Silverlight apps.  We do expect this to change quickly, so I don’t want to dwell there but had to bring it up as it sums today’s state of affairs.  WPF is pretty successful on its own, and ironically Silverlight is adding to that.  The people that were doing web before, are still doing web, but now on Silverlight.  The people that were doing desktop before, are more eager to move to XAML now that they see the whole picture. 

§  The .NET Framework  3.5 SP1 is on ~ 75% desktops world-wide. In the more developed countries the number is even higher.  Silverlight is catching up quick, but it is not there yet. As we continue to make progress deploying the framework there will be even more WPF apps out there.  I think both platforms will continue to grow on their respective space, and end up at some pretty high numbers in a year or two.  Adoption/deployment of the run-times is not mutually exclusive.

·         I heard the “lame excuses” to use WPF include “integrate with C++”, “full desktop .net access”, etc.  Sorry to break it to you, but we have a huge ecosystem with billions of dollars that fit into this space. Including our own Visual Studio, Expression Blend,  Microsoft Dynamics,  Office (Semblio) and many others.  The space does not sound “lame” to anyone at Microsoft.

 

 

About innovation/ feature investments:

The two products are in very different states:  

·         Silverlight is innovating very fast,  no doubt about it. They are also catching up in some areas, it is much easier to add Viewbox, or printing, or Styling, when you have a blue print, written code to (partially) reuse, lessons learned, and no legacy to maintain.   For these two tasks, same resources can accomplish more than in WPF’s two tasks (see below), consider the overall circumstances so you can conclude that within the core teams, the investments are not that different.    

·         WPF on the other side is innovating (e.g. touch, Windows 7 integration, ribbon, etc.)  while also doing maintenance ( e.g. performance, interop,  bug fixes).  Text, as easy as it sounds is a huge surface area in WPF, this was no small undertaking.  It was on our top 3 customer pains; needed to be done; lots of lessons learned and code from have already made it (or will make it ) into Silverlight.

 

Why some features appear in Silverlight first?

·         Silverlight is the common denominator.  It makes sense we start there for efforts like the control toolkit.  We have to code them there first.

·         Silverlight team is very agile and they have no dependencies.  WPF team ships with .NET,  there are huge pros and a few cons about that dependency.  We did learn from all your insights that the WPF team should try to be more creative and agile.  Can’t promise anything now, but rest assured Scott and Ian are listening.

·         Silverlight is aimed at a space with more competition.  We have to move quicker and invest to stay ahead of the competition. This is where investments outside of the core (like controls) pay off.  It is a needed, and welcomed investment. Yes, I did read, we should figure how to incorporate into WPF quicker;  we need to figure it out.

On Collaboration, I am surprised this is not noticed by all of you.  There is huge collaboration on both sides; WPF gets SL features, SL gets WPF features all the time.  We released the assembly portability, which is a new approach to sharing code, etc.
This collaboration is the critical component to long-term success;  we are not there today, but the direction is clear: over time, the platforms will converge for 95%  of the scenarios (maybe more).

 

As you all know I drink the Koolaid.  You also know I focus a bit more on WPF than Silverlight, so do consider me biased; all I can tell you is I am excited about Silverlight, and I am also not worried about WPF’s future.  

If you want to know my answer today:  what platform should I use?   

“The one that meets your business needs. If they both do exactly what you want today and keep you covered for future needs, then go Silverlight,  the lighter, common denominator that targets more platforms.  If on the other side, only WPF is doing what you need, then do adopt it without hesitation, keep an eye on Silverlight practices so you can maximize your ‘portability’ across the platforms,  give us some time,  we have really smart people ( like gossman) focused on getting the platforms to converge over time”

 

That is my 2c!  Probably added very little to your original thread, but wanted you to have the view  from inside and give you the ‘business’ explanation on why both WPF and Silverlight have a great future (and neither is dead to us).

Cheers & thanks to all of you for your candid thoughts on the thread; it has spiked lots of great conversations inside Microsoft.

 

Jaime Rodriguez, http://blogs.msdn.com/jaimer,  @jaimerodriguez  

[Peter O'Hanlon]

Jaime - I rather think that the collaboration is taken for granted by the disciples - after all, we get to talk to you guys, and we know that if we ask a question of one side, quite often the same person answers for both sides. If that's not evidence of collaboration, I don't know what is;-)

 

I've already posted my thanks for the things you're targetting with WPF for 4, so I'm happy with where you're targetting, but I do have to agree that there needs to be more of a push from MS to show the place of WPF. A big problem right now is that WPF is taking one hell of a hit in sites like Code Project, and people are blaming WPF for the performance of beta software. Right now, WPF is being used as a punchbag, which annoys the hell out of me - in fact, I got into one hell of an argument with the people who attacked the latest version - something that put me into a real minority on Code Project.

--
Peter O'Hanlon

[Bill Kempf]

I doubt our current product could be done with SL 4... though I've not
evaluated it to extensively, and may be wrong. Our application is very
large, so even if it could be done in SL 4, there'd be little benefit
as web deployment would be a hindrance at best. That's the whole
"choose the right tool for the problem" answer... even if we could do
this application in SL 4, it's more suited for WPF and that's what
we'll use. Many of the smarter folks will do that. Unfortunately, many
of those same smart folks also work for a PHB that watches industry
trends more than he pays attention to technical reasons. That's why
some of us are concerned about the (potential for a) PR problem.

I can only speak for myself. Despite the appearant message sent at the
PDC, I never had concerns for the future of either framework. It's
great to hear insights into the effort that was done on both, but
honestly, it just verifies what I suspected. From a technical
standpoint, I'm not concerned with the technical effort, as it's been
phenominal for both frameworks. I haven't seen tech advances like this
since the days when Visual Studio was released quarterly! Kudos to
everyone involved!

So, my concern isn't technical. It's just about the PR. I'm worried
about what the PHBs will say and do based on perception. :(

--

[Evan Lang]

I agree with the convergence idea. I think "Will we still have desktop
apps in N years?" isn't really the question. I think the better
question is "Will we still have browsers in N years?" With all the
crap my browser loads, all the resources it consumes, and all the
different apps it can run, it's looking a heck of a lot like an OS
unto itself these days. I imagine that web apps and desktop apps will
become increasingly difficult to tell apart, and will ultimately boil
down to a hybrid where developers decide which components should be
stored and operated locally and which should be bound to a server. As
it was pointed out, each client and each application has different
needs, and I personally see no reason why an app must only be 100% web
or 100% client.

Things like OOB and ClickOnce are critical to that transition, as well
as exposing more powerful native APIs like DirectX as web services and
the ability to execute safe, secure code at speeds equal to (or near
equal to) optimized native code. All have come a long way, but still
have a ways to go.

On Nov 20, 10:37 pm, "Laurent Bugnion" <laur...@galasoft.ch> wrote:
> Loving John's reply. Having the chance to work for a firm that is deeply involved with both technologies and with devs and designers who switch from WPF to SL depending on the projects they work on, I don't quite see what's all the fuss is about. As i said often, the story is one of convergence, not of competition. I recently had the chance to talk to a few prospective customers who are early in the process of moving from MFC or WinForms or ASP or ASP.NET (and in one case, from Java applets) to WPF or Silverlight. In all cases, which framework was to be used was very clear due to the requirements.
>
> One thing that needs to be better is the ClickOnce story (both the experience and the marketing should be improved) because i recently had 2 cases where the devs wanted to do SL when WPF+ClickOnce was obviously better, but they did not know about it (both had never heard of ClickOnce and were giddy when i demoed it to them). Other than that, and apart from the fact that I still think it would be cool if WPF had a better name and a shiny logo, i couldn't be happier about the recent developments in WPF/SL and about the convergence which is happening.
>
> Cheers,
> Laurent
> --
> Sent from mobile
>
> -original message-

> Subject: [WPF Disciples] Re: Future of WPF/Silverlight