Silverlight 4 or WPF 4?
A few weeks ago, the new VS2010 beta was released, including a long-awaited upgrade of WPF, which enables features like the Visual State Manager for WPF. Next to that, a beta of Silverlight 4 was released at PDC last week, which – amongst others – enables SL Out of Browser to run in a trusted environment, thus enabling it to access (parts of) the local file system and COM interop.
From that moment on, the internet has been buzzing with questions and concerns about when one should use WPF and when SL when building a rich app using the Microsoft stack. On ZDNET, an article appeared which stated that everything would be rebranded to Silverlight – so the term “WPF” will be obsolete in the (near?) future. We’ll just have different subsets of Silverlight. How this is going to be implemented remains to be seen. This is what the article has to say about that:
Some day — Microsoft won’t say exactly when — Silverlight and WPF are going to merge into one Web programming and app delivery model that, most likely, will be known as Silverlight, Brad Becker, Director of Product Management for Microsoft’s Rich Client Platforms, told me this week at TechEd. Now that the two share the same compiled assemblies, tools and the like, that idea isn’t really so far-fetched.
So, what do you do when you want to decide on using WPF or SL for an application? That’s probably a question a lot of people are asking themselves at the moment – this question for sure sparked some heated but very interesting discussions at my company. 🙂
Just stating “WPF for desktop clients, SL for web clients” doesn’t cut it anymore now that SL can run on the desktop, even on Mac, trusted. It even provides you with a very, very easy upgrade model (simplified: update the XAP on the webserver, and all clients, even the OOB installed ones, will be updated automatically).
Some business requirements automatically make the choice for you: need WS security standards? Use WPF. Need heavy 3D graphics? Use WPF. Need full local file system access? Use WPF. Do not try to get Silverlight to behave as a WPF client by using workarounds – if you need a workaround to get something done that’s included out of the box in WPF, it’s probably better to just use WPF.
Next to that, I – personally, not necessarily my company’s view – would use Silverlight, even for desktop applications. Why? Well, that’s more a matter of how I think applications will/should evolve than anything else.
Let’s elaborate on that a bit. It’s clear that the division between the online and offline worlds is fading. People want to be able to access their applications and data anytime, from everywhere. Silverlight is already a nice fit in this model: it runs in the browser and on the desktop when needed. We can now develop an application that can easily be installed locally or accessed through the browser, without actually having to develop 2 separate applications. And if you absolutely need two separate apps, one which has more features than the other, you could share most if not all your code.
Now, back to the “rebranding of WPF to SL”. I’m hoping that Microsoft, won’t just rebrand this, but that they’ll go for a new, truly pluggable model. At the project start, you should decide what requirements your application needs, and depending on those requirements, certain features will be enabled or disabled. The Silverlight Core CLR could be the base feature set (so: no more differences in XAML markup/features between SL and WPF), and if you need more functionality, your project should just reference the necessary assemblies, which would then be included in the XAP (of course, assembly caching and XAP shrinking should be used here).
This would allow for true plugability: does your application need to comply to the WS standards? Reference the necessary assemblies, and it will. Does your application need full access to the local file system? Reference the necessary assemblies, and it will, but it will of course disable some features in the online version of your app.
In a sense, what I’m aiming for is not plugability of certain features, and not just a few different sets of the .NET framework to choose from, but the ability to be able to plug in parts of the .NET framework when needed – much like you plug in third party controls. One base framework (based on SL’s Core CLR), and a pluggable model for all the other namespaces. Something to think about?
