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?
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! :)
> 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?
On Fri, Nov 20, 2009 at 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:
>> 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?
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:
> > 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?
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
> 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:
> > > 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?
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
On Fri, Nov 20, 2009 at 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> wrote:
>> 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:
>> > > 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?
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 ...
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
> > wrote:
> > 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:
> > > > 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?
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.
On Fri, Nov 20, 2009 at 11:13 AM, Colin Eberhardt <colin.eberha...@gmail.com
> 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 ...
> 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
> > > wrote:
> > > 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:
> > > > > 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?
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.
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Daniel Vaughan Sent: Friday, November 20, 2009 8:32 AM To: WPF Disciples Subject: [WPF Disciples] Re: Future of WPF/Silverlight
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.
On Behalf Of David Anson Sent: Friday, November 20, 2009 12:47 PM To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Re: Future of WPF/Silverlight
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Daniel Vaughan Sent: Friday, November 20, 2009 8:32 AM To: WPF Disciples Subject: [WPF Disciples] Re: Future of WPF/Silverlight
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.
> -----Original Message-----
> From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Daniel Vaughan
> Sent: Friday, November 20, 2009 8:32 AM
> To: WPF Disciples
> Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> 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.
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... ;)
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Daniel Vaughan Sent: Friday, November 20, 2009 10:37 AM To: WPF Disciples Subject: [WPF Disciples] Re: Future of WPF/Silverlight
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.
On Nov 20, 6:46 pm, David Anson <david...@microsoft.com> wrote: > 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
> -----Original Message----- > From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Daniel Vaughan > Sent: Friday, November 20, 2009 8:32 AM > To: WPF Disciples > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> 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.
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?
----- Original Message ---- > From: David Anson <david...@microsoft.com> > To: "wpf-disciples@googlegroups.com" <wpf-disciples@googlegroups.com> > Sent: Fri, November 20, 2009 1:45:08 PM > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> 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... ;)
> -----Original Message----- > From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On > Behalf Of Daniel Vaughan > Sent: Friday, November 20, 2009 10:37 AM > To: WPF Disciples > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> 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.
> On Nov 20, 6:46 pm, David Anson wrote: > > 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
> > -----Original Message----- > > From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] > On Behalf Of Daniel Vaughan > > Sent: Friday, November 20, 2009 8:32 AM > > To: WPF Disciples > > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> > 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.
> 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?
> ----- Original Message ----
> > From: David Anson <david...@microsoft.com>
> > To: "wpf-disciples@googlegroups.com" <wpf-disciples@googlegroups.com>
> > Sent: Fri, November 20, 2009 1:45:08 PM
> > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> > 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... ;)
> > -----Original Message-----
> > From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On
> > Behalf Of Daniel Vaughan
> > Sent: Friday, November 20, 2009 10:37 AM
> > To: WPF Disciples
> > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> > 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.
> > On Nov 20, 6:46 pm, David Anson wrote:
> > > 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
> > > -----Original Message-----
> > > From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com]
> > On Behalf Of Daniel Vaughan
> > > Sent: Friday, November 20, 2009 8:32 AM
> > > To: WPF Disciples
> > > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> > > 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.
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
On Nov 20, 11:07 am, Eric Burke <ebu...@yahoo.com> wrote:
> 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?
> ----- Original Message ----
> > From: David Anson <david...@microsoft.com>
> > To: "wpf-disciples@googlegroups.com" <wpf-disciples@googlegroups.com>
> > Sent: Fri, November 20, 2009 1:45:08 PM
> > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> > 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... ;)
> > -----Original Message-----
> > From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On
> > Behalf Of Daniel Vaughan
> > Sent: Friday, November 20, 2009 10:37 AM
> > To: WPF Disciples
> > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> > 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.
> > On Nov 20, 6:46 pm, David Anson wrote:
> > > 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
> > > -----Original Message-----
> > > From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com]
> > On Behalf Of Daniel Vaughan
> > > Sent: Friday, November 20, 2009 8:32 AM
> > > To: WPF Disciples
> > > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> > > 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.
"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 :(.
On Fri, Nov 20, 2009 at 3:54 PM, Justin Angel <J...@justinangel.net> wrote:
> 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
> On Nov 20, 11:07 am, Eric Burke <ebu...@yahoo.com> wrote: >> 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?
>> ----- Original Message ---- >> > From: David Anson <david...@microsoft.com> >> > To: "wpf-disciples@googlegroups.com" <wpf-disciples@googlegroups.com> >> > Sent: Fri, November 20, 2009 1:45:08 PM >> > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
>> > 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... ;)
>> > -----Original Message----- >> > From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On >> > Behalf Of Daniel Vaughan >> > Sent: Friday, November 20, 2009 10:37 AM >> > To: WPF Disciples >> > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
>> > 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.
>> > On Nov 20, 6:46 pm, David Anson wrote: >> > > 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
>> > > -----Original Message----- >> > > From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] >> > On Behalf Of Daniel Vaughan >> > > Sent: Friday, November 20, 2009 8:32 AM >> > > To: WPF Disciples >> > > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
>> > > 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
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.
On Thu, Nov 19, 2009 at 7:35 PM, 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:
>> 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?
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.
On Fri, Nov 20, 2009 at 12:54 PM, Justin Angel <J...@justinangel.net> wrote:
> 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
> On Nov 20, 11:07 am, Eric Burke <ebu...@yahoo.com> wrote: > > 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?
> > ----- Original Message ---- > > > From: David Anson <david...@microsoft.com> > > > To: "wpf-disciples@googlegroups.com" <wpf-disciples@googlegroups.com> > > > Sent: Fri, November 20, 2009 1:45:08 PM > > > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> > > 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... ;)
> > > -----Original Message----- > > > From: wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] On > > > Behalf Of Daniel Vaughan > > > Sent: Friday, November 20, 2009 10:37 AM > > > To: WPF Disciples > > > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> > > 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.
> > > On Nov 20, 6:46 pm, David Anson wrote: > > > > 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
> > > > -----Original Message----- > > > > From: wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] > > > On Behalf Of Daniel Vaughan > > > > Sent: Friday, November 20, 2009 8:32 AM > > > > To:
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-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Bill Kempf Sent: November-20-09 1:35 PM To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Re: Future of WPF/Silverlight
"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 :(.
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.
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 <mbrow...@gmail.com> >To: wpf-disciples@googlegroups.com >Sent: Fri, November 20, 2009 4:59:46 PM >Subject: [WPF Disciples] Re: Future of WPF/Silverlight
>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.
>On Thu, Nov 19, 2009 at 7:35 PM, 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:
>>>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?
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.
On Fri, Nov 20, 2009 at 5:13 PM, Justin Angel <J...@justinangel.net> wrote: > "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.
> 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-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] > On Behalf Of Bill Kempf > Sent: November-20-09 1:35 PM > To: wpf-disciples@googlegroups.com > Subject: [WPF Disciples] Re: Future of WPF/Silverlight
> "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.
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
On Sat, Nov 21, 2009 at 12:30 PM, John Gossman <gossmans...@gmail.com>wrote:
> 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.
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 From: John Gossman <gossmans...@gmail.com> Date: 21.11.2009 02:31
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.
