Thoughts on Silverlight 3 and the future of desktop development.

There are rumors in the community that WPF adoption will suffer in favor of Silverlight.
I would leave it as "rumors" coming from outside of Microsoft. WPF is the backbone of Blend and design. It's used heavily in VS2010 shell. Microsoft needs WPF more than anyone else for other internal products.
WinForm is here to stay, if you're developing 2-tier apps that needs performance and does not require all the WPF installations, but if you're going to do any 3-tier, WinForms is much harder to maintain than SL. I think SL will become a prime choice of building 3-tier desktop (with OOB).
Just me two cents!
..Ben

The fact that WPF is used by MS internally is one thing. Whether the users will be using WPF to build their [desktop] applications, or they will use something else is another.

Indeed, a lot of users will prefer to stick to WinForms for now, as it is familiar and proven. With products like RadControls for WinForms offering animations and WPF-like features, users will surely have even less incentive to switch to WPF.

Good point Yordan;

I bet Telerik (WinForm team) goes through a lot pain to make WinForm look and feel like WPF.
Great job!

..Ben

Isn't the point that Silverlight and the OoB experience is sandboxed meaning that such applications, while powerful as network aware applications, will be severely limited when it comes to accessing the full resources of the host machine?

In terms of building rich desktop applications then I very much see WPF being around for some time. It's up to us as developers to push out the applications that use it.  At the moment, WinForms are used more now because a greater install base of our customers (particularly for internal business applications) may not have the runtime support in place for WPF.  This will change over time.

Silverlight is the technology to GO, 1-source for client and browser application! One drawback for the current version: SL needs better and easier access to other databases (oracle) besides sqlserver and binding data should be as simple as in the Winforms world.
I am glad to see that Telerik recognize the importance of SL and provides us more and more SL controls. I hope also that Telerik ORM will give us the "easy" way of binding data between a SL control an a (oracle) data source.

I agree with Simon regarding the burden of re-distributing the .NET 3.5 Framework, which includes WPF. It's hard to justify building a stand-alone desktop application with WPF and then ask users to download and install .NET 3.5 as a pre-requisite.

However, I disagree with Simon's assessment that this will "change over time." In fact, I think the .NET Framework is evolving so rapidly that it will always be a moving target - by the time Windows 7 is released with .NET 3.5 (or 4.0) installed by default (and I'm just making an assumption here), the next generattion of the framework will soon follow - and you're back to square one.

As a commercial software development company, we're still using a mix of C++ / MFC for many desktop applications, and are just now starting to move to C# / WinForms. We're moving in that direction because so many computers finally seem to have .NET 2.0 installed at this point - for those that don't, we can effectively roll up .NET 2.0 applications into a reasonably sized installation package. Just not true for WPF / .NET 3.5.

The Silverlight v3 out-of-browser features are very interesting from a software distribution perspective, but will always be constrained by whatever security limitations they (necessarily) enforce. I think this may be great for many n-tier line-of-business type applications, but there will always be a lot of desktop applications that don't fall neatly into this category.

For these reasons (among others), WinForms is going nowhere. And I'm glad that Telerik is still pushing to improve their WinForms offering while other component vendors seem to be abadoning it prematurely.

I don't think that the argument for making the users download the 3.5 Framework holds much water.  The various versions of the Framework are now distrubted via Windows Updates which means that most users already have the 3.5 Framework unbeknownst to them.  If they don't then they are probably on a Corporate Network and the IT guys just need to do a mass, or targeted, deployment.  And of course, Vista and Windows 7 both come with versions of the Framework pre-installed.

In response to Simon....While SL is sandboxed, it does not mean that it is restricted from using the full processing power of the CPU, and now with SL3 the GPU.  It does mean that you won't have access to peripherals, etc.  But, if your building a Line of Business application you may not need that.  If you do, and you've got some SL experience under your belt, I would think that you would opt for WPF since you would be leveraging a single skill set in a more powerful way.

Now WinForms vs. WPF...I personally think that older applications already in WinForms will likely remain there unless there is a solid business reason for moving to WPF.  However, as more developers encounter WPF and as user expectations increase, the move to WPF will be inevitable.

About the ".NET Framework distribution".
One of our customers decided to have a new application in WPF - so he hat do "roll out" .NET 3.5 SP1 on about 800 clients.
The administrative time it took (include testing and so on) was less than 3 hours.
The distribution it self was nothing more than scripting the runtime executable.
And as told before - it's inside vista, it's available via windows update - and it can "install itself".
So that's nothing that really matters.

There is also a pattern (and there will be project templates - currently beta) for building WPF+SL applications in "one step".
SL 3 gives a lot of things which removes barriers in sharing code (XAML / CS).
On the other side we get VSM for WPF...
And so on. There is a nice presentation on MIX90 from Jeff Wilcox telling about SL / WPF apps.

BUT - there are differences - one most important is the security.
That means that there are things you will never be able to do with SL.
For an example we have built a library for a USB hardware board
http://forum.velleman.be/viewtopic.php?p=8326#p8326
Due to security it will never be possible to access HID from SilverLight.
Anyhow in LOB applications there is normaly no need for HW access.

Now to the comparrison about WinForms and WPF (or SL if you want).
Yes telerik controls give a great look to your app - and you can give your WinForm applications a "nearly WPF" look and feel.
BUT it is still a WinForm app.
And this is a point where I really want to make some things clear.
A developer is (mostly) NOT a designer - and that means a lot.
Scott Hanselman had a session on PDC 2008 talking about his Baby Smash project.
One very interesting thing for me is the point about his "config dialog".
You can see this dialog here: http://www.hanselman.com/babysmash/screenies.htm
In his session he showed the "original dialog" - or let's say the "developer version".
He gave this dialog to a friend - a designer - and the dialog on the screenies is the result of about 1.5 hours designer work.

And this depends on WPF (SL). It's one of the main features of WPF that you have a clear seperation of desing and code.
And there are the tools for the designers (Blend and so on).
So if we wanna build a "great looking" application we code it in WPF - and hand out the thing to a designer who does those things we are not able to do - because it is his profession to make things look great.

This seperation (and the technics / tools) are not available for WinForms.
We work with telerik WinForm controls - BUT - and that's the thing we do (have to) a lot of things in code behind.
It's not a big thing - but for an example if I want to give a grid cell a red background when a numeric value meets some conditions - I have to add some (simple) lines of code.
Although they are simple - this is beyond the knowledge of a designer.

So if it comes to "great design" - WPF (SL) is not comareable to WinForms.

The last point about WPF / WinForms.
Starting with native C windows SDK we made the tour over MFC apps to WinForms.
We entered the .NET world a year before it was introduce at PDC 2000.
So we worked for quite a long time with WinForms.
And due to project stress we didn't have much time when WPF comes out.

We had to find out the hard way that WPF is VERY DIFFERENT to WinForms. And that switching to WPF means a lot of learning.
BUT we finally did it :)
They (shortened) story about it.
A customer orderd some software - it took us about 2 weeks design - and 5 weeks coding till we reached a point where the customer was not able to provide data (the bought a machine - and the manufacturing took much longer than expected).
Anyhow - the project was on a 80% (60% of UI) done state when we hade to pause it.
A few months after this a friend asked me if I could build a roulett application for him.
I decided to do it in WPF - just to get expirience with this technology.
Although I was "informed" about WPF it ment a lot of learning to get the things going.
But finally I could manage to build a "real WPF app" - not a "XAML using WinForms" application :)

And than my customer came up with data - and I asked him about building the app in WPF.
The customer is quite big - but after about a week "discussion and evaluation rolling out .NET 3.5 SP1" we got a go.
We threw away the whole UI code and rebuild the thing from scratch in WPF.
And we were done in about 14 days :)
This was the time we (at least) expected to need for finishing the WinForms client.

Conclusion:
WPF (SL) is totally different to WinForms.
"Design isolation" is one of the great things in WPF.
And it takes some time to really build WPF apps.
It's compareable to C to C++. The "beginners C++" things are C code with new syntax.
And it takes time to understand OOP which is the base to write  real C++ code.

If you find yourself writing a handler for "Combobox_SelectionChanged" just to hand out data to some dependent controlls there's something wrong. :)
If you do instead things like <...ItemsSource="{Binding ElementName=combo1, Path=SelectedItem}" you are on the right way.

WPF (SL) is not a matter of "great looking" UIs - it's a very different approach to build applications.

And so finally the question about the video above could be simply answered:
If you did not have to write code behind for the thing it is WPF :)