MIX Update: WPF vs. Silverlight

I’ve heard a lot of talk around MIX this week about Silverlight obsoleting WPF. Developers are asking “why would I develop a WPF app when I could do the same thing with Silverlight and have it run in a browser?”

I can think of two big reasons why WPF is still relevant:

1) WPF has lots of cool accelerated 3D support that Silverlight lacks. Silverlight lets you build rich applications; WPF lets you build even richer applications.

2) Silverlight runs in a sandbox. Among other things, it can’t access the local file system. (It does support isolated storage so data can be persisted locally, but isolated storage is highly virtualized and is a far cry from unfettered file system access.) WPF is the better choice for building traditional document-handling applications.

There are other reasons WPF is still the right choice for some apps, but admittedly, Silverlight blurs the line between traditional apps and browser-based apps and it opens up a whole new world of possibilities for the latter.

One of the coolest demos I saw today was one in which C# code was called from JavaScript. Imagine: you have a bunch of complicated logic implemented in C# (maybe a spell checker or something like that) and you’d like to download that code to the browser and execute it locally. In the past, you had to call back to the server (perhaps using AJAX) or translate all that C# code into JavaScript. Now you can compile the C# code, download it to the browser, and call it from C# or JavaScript. Now that’s cool!