WPF/E

Tim Anderson has some commentary on WPF/E. He sums up his thoughts like this:

In the past Microsoft has been characterised by its single-minded focus on Windows. Why does it now want to create a cross-platform runtime engine? It is the clearest sign yet that it can no longer base its entire strategy on the Windows client monopoly.

Microsoft’s problem is not only Apple and Linux chipping away at its desktop empire, but more seriously the rising importance of two other computing platforms where it is a minority player. The first is the web, and the second is mobile devices. It happens that WPF/E is also intended for device use, though Microsoft will probably struggle even more than Adobe to get its runtime embedded onto third-party hardware.

It is completely untrue to say that Microsoft has been characterised by a "single-minded focus on Windows." The fact is that Microsoft ported the most important software in the world, other than Windows to Mac a long time ago. It's called Office. IE runs on Mac. Rotor runs on Linux. Microsoft has an award winning set of services written for UNIX computers. etc. etc. Yes, most of Microsoft's products are written for Windows. Making WPF/E available doesn't change that fact, nor does it change the fact that most of Microsoft's desktop apps are going to remain Windows only. So, the statement that, "It is the clearest sign yet that [Microsoft] can no longer base its entire strategy on the Windows client monopoly" are completely false. First off, Microsoft has never based its entire strategy on the Windows client. Secondly, those parts of Microsoft's strategy that do involve the Windows client are going to continue to do so.

Tim's comments are the result of misunderstanding of the nature of browser plugins like WPF/E and Flash. The very fact that Tim states that, "Potentially, WPF/E could combine the design appeal of Flash with the application strength of Java" shows that he really doesn't know what he is talking about. WPF (not WPF/E) is the platform that combines design appeal with application strength. Both Java and the .NET framework can do leaps and bounds more than either WPF/E or Flash and that isn't going to change. Browser plugins do not now, and will not any time in the future, be intended for building traditional desktop applications. They certainly don't support 3D functionality required for games and can't take advantage of huge portions of the platforms they are running on. These technologies are display only for the most part. They generally assume that you are going to have a web server somewhere to store data and query data and that your connection to the internet is going to remain active.

What are these client side browser plug-ins good at? Right now, they are best at augmenting existing sites with compelling media. WPF/E shows a lot of potential for replacing AJAX as a means of providing rich interactivity on the web, however, the kinds of apps we are talking about replacing are HTML / DHTML / Flash apps or your internal apps that probably could have been taken care of with HTML / DHTML / Flash to begin with. I'm sure someone will try to build a Word Processor with WPF/E. I'm sure someone will try to build games with WPF/E. I'm sure someone will try to build all kinds of abominable applications with WPF/E, but they aren't going to measure up to their client side counterparts (take a look at Office 2007, there is no way you could build it with WPF/E).

So, what is Microsoft's move to provide a Flash alternative a sign of? First off, Microsoft has realized that there is a lot of money to be made in the web development space. This isn't a new realization by any means, but the web has finally transitioned from a place providing merely content to a place providing rich services and functionality. As a result, we need a technology for the web that is designed for providing these types of rich services and functionality. HTML is a content markup language, not a programming language. HTML was not designed for building applications, and so it makes developing them painfully hard. If you are fortunate enough to use something like ASP.NET, you can hide most of this complexity and simulate traditional application development paradigms, but the larger and more complex your application's user interface gets, the more and more you will realize just how far short HMTL falls. Javascript can allow you to get around some of these barriers, but even DHTML is still lightyears behind traditional application technologies when you compare the richness of even the best DHTML apps with simplest Windows applications. The funny part of this story is that if it wasn't for Microsoft's innovation with DHTML, the browser would not be anywhere close to the application platform it is today. Innovations like the XmlHttpRequest object and the ContentEditable attribute form the backbone of the AJAX web. However, Microsoft is no longer allowed to innovate in this area. People complain when Microsoft gives developers anything that is not "standard compliant." They claim that Microsoft is trying to break the web and screw over anyone that doesn't use their browser. Even if there was no whining to deal with, before these new features could be of any use, Microsoft would still have to push any new browser features through the W3C (which could take years) then wait for Firefox, or Opera, or whoever the new kid on the block happens to be to implement them (which could take a few more years) only to have the technology obsolete by the time its use is widespread enough to make it useful. Microsoft's decision to provide us with WPF/E is not a sign that they have lost the war on the desktop platform side. Microsoft's decision to provide us with WPF/E is a sign that Microsoft realizes they will never win the browser war. There are too many players, the technology evolves too slowly, and they don't control any of it. By providing a browser plugin, they get to bypass the process entirely and innovate at their own pace.

[1] http://www.itweek.co.uk/itweek/comment/2156484/microsoft-sees-writing-wall