I saw that Karl had been busy on the plane and had written this post around sharing code between WPF and Silverlight and so I wanted to flag that up here.

It links up pretty well for me in that during my “Beyond Silverlight with WPF” session at DevDays last week I talked about how people often see Silverlight and WPF as competing technologies;

and that I often get asked the question of

“Do I build for the browser or do I build for the client”

and there’s an implicit link of the “browser” aspect of this to Silverlight and the “client” aspect of this to WPF. Now, I think there are various reasons why people build for “browser” or for “client” such as;

and we even talked about it a little in the video that we made up here but I think it’s getting too complex to talk just in terms of “browser” or “client” these days in that I think those boundaries are blurring in that Silverlight ( especially V3 ) reaches out in some ways to the desktop and WPF reaches out in some ways to the browser as in;

and so it becomes a more nuanced discussion than just “browser” or “client” and in my session at DevDays I tried to come up with a list of Microsoft’s UI “technologies” and rate them against various criteria – picking out Silverlight and WPF;

I really see these criteria as being how someone decides whether they build with technologies like Silverlight or WPF – criteria like;

• Richness of UX
• Deployment ease
• Developer productivity
• Platform integration (i.e. can I print? can I enumerate the network cards? can I use a local database? can I use WCF? WF? etc )
• Online/Offline
• Runtime availability
• Healthy set of controls available
• Strength of tooling
• Ability to meet security requirements

so it becomes a much more rich choice than “browser” versus “client” and the benefit that I see from looking at what Microsoft’s doing with Silverlight and WPF is that you get a lot of re-use from the knowledge and skills that you have around .NET, XAML…

and that there’s also the potential for re-use of code and XAML across the two frameworks although I did say that this isn’t perfect yet but that we take that Silveright->WPF subset of code and XAML very seriously and work hard to try and make sure that the compatibility level is as high as it can be and that’ll improve as we go forward.

Anyway, job done – Karl’s post is referenced! 🙂