Are WPF and Silverlight on a collision course?

Question

It seems like these two technologies, already similar, are on a path to merge into a single technology. There are a lot more WPF-like controls in the Silverlight toolbox, and WPF now has Silverlight's VisaulStateManager. At this point, it's probably fair to say that Silverlight has even surpassed WPF in terms of the number of themes available.

How long until these two technologies become one? How long until the difference between a rich client app and a rich browser app is a simple compile-time setting?

EDIT

Let me clarify my question. I realize that any browser application needs to run in a "sandbox" for security reasons, and I also understand the desire to keep the browser plugin as small as possible, but there are several minor differences between the two technologies that could probably be massaged out without compromising either of these goals. For example, there could be a lot more overlap between UI controls and themes. Today, you can't just use a Silverlight theme in a WPF app, but how much of a leap would it be for Microsoft to make this possible?

Answer 1

XAML and databinding may become closer between the two
but the rest of the framework will probably never be the same.
For once, you can not automate an Office application using Silverlight.
And that may never happen, unless MS decides to open a bridge of some sort
between the plug-in and the .NET Framework.
Security, consistence, and great UI are main driving forces in Silverlight.
If you can do something in Windows that you cannot do in Mac than
consistence is lost.

Answer 2

Silverlight installations has its own libraries built for specific operating systems. We as developers use what microsoft gives us that can run on those systems. WPF is full trust to the windows operating system which uses specific windows api calls.. So i'd say never will they merge.

Answer 3

I don't think they'll ever merge into one product. Microsoft has intentionally left a lot out of Silverlight to keep its footprint small. And then there's a plethora of security issues Silverlight must abide by when running in a browser. And of course they've designed it so it'll run on a PC or a Mac (unfortunately the same can't be said for the .NET Framework).

I am happy to see resources shared between WPF and Silverlight though. They were supposed to be similar from the beginning. As a result, it's relatively easy to port a Silverlight project into WPF. On the flip side, it's not quite as easy going from WPF to Silverlight simply because WPF has always had more features, but that's just the nature of the beast.

UPDATE:

So your revised question is interesting. It would be cool if Microsoft could make it possible for you to basically flip a switch to change the behavior of your app between Silverlight-like functionality and WPF. They would be facing a great deal of challenges though, not only with security but with the fundamental behaviors of some of the lightweight Silverlight controls vs the feature-rich WPF controls. These differences could potentially complicate things for the developer even further.

For example, in WPF there's a built-in multiple undo & redo system in the textboxes. In Silverlight there is no such thing so I actually had to write my own. In order for the developer to account for things like that they'd have to do build a lot of feature-checks into the application.

With all that said, I suppose a compile-time switch as you described might be feasible. But I still think it's unlikely Microsoft will create this kind of capability any time soon.

Answer 4

Yes we will see that WPF and Silverlight becomes more and more alike, if the acutely will be merge? maybe It's not impossible but what we will see is just that what you stated that they will be more alike. So in the future you will not implement WPF OR Silverlight you will just implement XMAL.