Will Silverlight Controls Become More WPF Like - A Personal Opinion
I was told when I joined Microsoft that I no longer had personal opinions about matters having to do with Microsoft software, and certainly not about Silverlight. As a "Blue Badge" I'm just exposed to too much confidential information to be seen as offering informal speculation or personal opinions, or so they said.
It might even be true; who can really keep straight what you hear in back channels and what you hear inside your head (you don't hear little voices in your head? How do you get any work done?).
About a week ago a very smart fellow wrote to me asking for a list of the differences between Silverlight and WPF. I responded saying that I didn't think such a list existed and (I added) "the list is shrinking all the time." He immediately picked up on that and asked me if I was hinting that there is a plan to make Silverlight 2 considerably more like WPF.
Answer: I don't know. And I wouldn't say (we really are careful about not announcing features until they're cooked).
But let me step away from what I do know and put on my rational individual non-employee hat and observe (keeping in mind how often I've been wrong over the past 2 decades!)....
Silverlight was originally named WPF/E. The Silverlight controls are clearly and markedly very similar to and almost a subset of the WPF controls and Silverlight itself is very similar to and almost a proper subset of WPF - so much so that you can take a Silverlight application and plop it into a WPF application and it works (or it does after some tinkering; or it does after a lot of tinkering depending on how you wrote it and how late it is). So we can't be that far. It is just that some things don't work quite the way you expect.
For example, I blogged earlier about the fact that click events don't bubble. I sorta' kinda' understand why not, but they don't in Silverlight and they do in WPF. Will that change? Will they, eventually bubble in Silverlight? I don't know.
But again, let's think about the pressures on the programmers logically.
Here are these guys who built the Silverlight controls (e.g., the button) who are incredibly and justifiably proud of what they've wrought. They use the controls themselves. They also read the email from customers and from WPF programmers and from others, many of whom are confused by (or outraged by, or annoyed by, or mildly bemused by) the differences between Silverlight and WPF behavior.
I'm guessing they'd like the Silverlight click event to behave the same as the WPF click event. Either they think the Silverlight way is the right way for it to behave and they're in the offices of the WPF-control programmers banging on the desk trying to get them to change, or they are now looking again, perhaps banging on their own boss's desk (or on their own heads).
Now, again I don't know but I'm guessing that there are competing pressures. Two I can think of are money and time. After all, you don't just fix the button; you gotta fix all the controls. And you don't just fix Click, you gotta' fix the way all the events work; either you decide to match the routed event handling in WPF exactly or you decide on a different compromise.
Next, there's lots of other features waiting to be added. And, of course, there are lots of other cool products waiting to be built. And, oh yeah, some developers are still being hired, some are being promoted, some are taking new jobs.... so there are pressures to move on and let things be.
Now, I don't know, but experience suggests that Microsoft has typically placed high value on (a) customer satisfaction and (b) developer respect and (c) common code and (d) not looking stupid. So if I were a betting man, I'd bet that one day ASP.NET and WPF and Silverlight will all use code (mostly?) in common. On the other hand, I'm not sure I'd bet that we'd get there before all three technologies were supplanted by new and better technologies; which is one of the great pleasures of living in a world of rapid change.
But I don't know and I couldn't say if I did.