Jaime Rodriguez has just released a fantastic 3-part series summarizing the big things to directly or indirectly come out of Mix09. I highly recommend it for anyone working within WPF and/or Silverlight:
It’s great to get a little insider insight into the thinking behind Microsoft’s ongoing client strategy.
First, I have to give huge props to Microsoft for throwing an excellent party in Vegas this past week! The week was definitely packed with excitement and backed by great content. Be sure to check out the recorded sessions if you were not able to attend Mix09.
This post represents my response to this year’s big unverbalized question…
What about WPF?
Yes, this year’s conference felt like it was all about Silverlight 3. I think Microsoft would readily acknowledge that this was by design (no pun intended). And this was actually fine with me, since the Silverlight platform has made such great strides over the past couple of years. It certainly deserves the attention it is now getting.
I have a reputation for making fun of Silverlight from time to time. Truth be told, I bare no ill will toward Silverlight at all. I’ve even delivered Silverlight training on several occasions. I think of her as a kid sister to WPF (which plays the role of big sister, in case you were curious about either platform’s gender). Privately I’m pulling for Silverlight to make good, but that doesn’t stop me from publicly taking shots at her whenever the opportunity arises. It’s all in good fun… really! 🙂
I’m not exactly sure what role I’d give myself in all of this. Some might say that WPF and I are BFFs, but I’d argue against the latter F. To me, "forever" is a word that has no place in technology. When it comes to WPF, my devotion only goes as far as the platform presently supports. I am her student; I am her practitioner; I am even her disciple; but make no mistake… if something better comes along, I will turn her out like a two-bit whor… rible analogy! Let me change directions…
Based on what I see on the horizon right now, I think WPF and I still have a bright future together. Silverlight gets more impressive with each release, but it has quite a ways to go before it reaches parity with WPF. I just spent the better part of a conference watching web developers "ooh" and "ah" over features that I’ve been using in WPF for years now. (Imagine how they’d feel if they had something as basic as a trigger! See… there I go again… I just can’t help myself. ;))
Additionally, I’m a platform guy. So much of what I do now requires a full trust environment with access to platform APIs. Until Silverlight breaks out of the sandbox and allows me to harness platform-specific features (which is not likely in the near-term, since it is so focused on cross-platform reach and a small footprint), I think WPF and I will stay pretty tight.
Why bring all this up now?
I’ve received a number of… shall we say… "concerned" inquiries lately about the shrewdness of adopting WPF for new or future projects while Microsoft has such an obvious slant toward Silverlight.
My honest recommendation to anyone deciding between WPF and Silverlight is unchanged over the last couple of years. The platform has to be chosen based solely on the project requirements. If Silverlight meets the requirements of your project and you need cross-platform reach, then you should definitely target Silverlight. End of story.
On the other hand, if you’re developing a full trust, Windows application, you will likely be far more successful with the more mature (and in my humble opinion, more elegant) big sister, WPF.
Impending Doom
Some emails have expressed an explicit fear that WPF is about to be abandoned by Microsoft and then disappear completely. Let me put my response to such concerns in terms that only a geek can truly appreciate…
To allay your fears, let me point you toward two very big buoys floating in the waters around Redmond: Expression Blend and Visual Studio 2010. The user interfaces these products are actively being built in WPF. Blend always has been a WPF application. For information on the upcoming Visual Studio 2010 UI, check out Jason Zander’s blog. Feel free to anchor yourselves to these buoys. If these projects change direction, make sure you follow! (Can you imagine a Visual Studio user interface written in Silverlight? Even I think that would be awesome!)
I would also point out that many new features highlighted at Mix09 actually represent nice WPF advances too. I know Silverlight received most of the glory, but new Blend 3 features like Sketch Flow, Behaviors, and the new Adobe importers are actually just as pertinent to WPF as they are to Silverlight. And of course, there was the sneak peak at WPF 4.
The Big "If"
So what happens down the road "if" Silverlight does reach parity with WPF and it finally breaks out of the sandbox?
Should that ever happen, my response to potentially losing WPF would basically be a shrug and a big, "So what?" If Silverlight v.Next++ gives me everything I need for Windows client development and supports the same collaborative workflow as WPF, then why would I (or anyone) mourn the loss of WPF? At that point, I’d be more concerned if WPF *was* still around.
Again, let me be clear… I think this latter scenario is a big "If" and should things go in that direction, I don’t think we’re talking near-term. Microsoft can move very fast when the correct motivations are in place, but even at full speed, I think this would be a multi-year scenario.
Again, my take is that nothing lasts forever in technology. Both WPF and Silverlight will eventually be replaced by something bigger and better… or maybe smaller and better… who knows? For now, I’m a WPF junkie and a Silverlight user.
Now the Important Stuff…
Here are the Sudoku puzzles I conquered on my return flight from Vegas: One, Two, and Three. (See JAGS 10K Instructions for mouse play.)
Yep, three of them! Usually, I only make it through a single puzzle, but I was unexpectedly bumped to first class on this flight where I basqued in the glory of geek icons such as Scorbs, The Gu, the WPF Wonder Man, and even Nate Dunlap! Their collective auras must have increased my puzzle IQ.
I recently had the pleasure of presenting some rather advanced WPF concepts (along with some cool tips and tricks) to a group of smart folks. Unfortunately, I ran up against time constraints and was forced to drop the data binding portion of my talk. I’m a little bummed about not being able to show one cool trick that I use a lot, so here it is…
Call me lazy (really, I’m okay with it), but I’ve never been wild about having to declare my value converters as resources before using them. It’s just one extra step:
<Window.Resources> Â Â <src:MyConverter x:Key="MyConverter" /> </Window.Resources>
And then later the converter must be specified using a StaticResource reference, which incurs some overhead (albeit small overhead, in the grand scheme of things) for the resource resolution:
<TextBlock Text="{Binding SomePath, Converter={StaticResource MyConverter}}" />
I often choose to skip the middleman. Instead of using the StaticResource markup extension to look up a converter, I simply derive my value converter, itself, from MarkupExtension. Then I return an instance of it in the ProvideValue() override.
I have to assume there are plenty of others using this approach too. (It’s clever, afterall, but that’s about the extent of the hyperbole I’d grant it.) If you’re not one of them, I simply wanted to put it out there as a potential trick for your arsenal.
Below is a super simple example of a dummy converter (typically used to debug bindings) that does this:
public class DummyConverter : MarkupExtension, IValueConverter {     private static DummyConverter _converter = null;     public override object ProvideValue(IServiceProvider serviceProvider)     {         if (_converter == null)         {             _converter = new DummyConverter();         }         return _converter;     }     #region IValueConverter Members     public object Convert(object value, Type targetType, object parameter,         CultureInfo culture)     {         return value; // set breakpoint here to debug your binding     }     public object ConvertBack(object value, Type targetType, object parameter,         CultureInfo culture)     {         return value;     }     #endregion }
The above class creates a singleton dummy converter that can be used across my app without any resource lookup. The XAML usage is now simply this:
<TextBlock Text="{Binding SomePath, Converter={src:DummyConverter}}" />
This is much better, to my lazy way of thinking.
