Windows Presentation Foundation now ready, too late

The immortal film The Railway Children has a scene in which a band plays during an award presentation. Unfortunately a series of false starts delay the performance, until finally it all comes together and the music begins. The camera pans – the audience has already departed.

Is it like that for WPF (Windows Presentation Foundation), Microsoft’s user interface framework which is built on .NET and DirectX and was intended to replace the ancient GDI (Graphics Device Interface) and GDI+?

In this new post I make the case that with WPF 4.0 is the framework is now truly ready to use, not least because Microsoft itself is using it in Visual Studio and the interaction between these two teams has solved a number of problems in WPF.

But who now wants to develop just for Windows? Well, it makes sense in some contexts, though I note that in the Thoughtworks paper on emerging technology and trends about which I wrote yesterday, neither Windows nor WPF gets a mention. Nor for that matter does the Mac, Linux, or OS X, though iPhone and Android feature strongly. The only emerging desktop technology that interests Thoughtworks is the browser.

19 thoughts on “Windows Presentation Foundation now ready, too late”

  1. I tend to agree with you. However, Silverlight 4 apps – with their out of browser capability – are interesting in the same way that Adobe AIR apps are interesting. These blur the line between web and desktop apps, and with Silverlight use a cut down (and mixed up) version of WPF.

  2. I believe thoughtworks is off in their assessment, I don’t know many people that actually like web application, not their user interfaces nor their development platforms. I don’t understand why we cling to these technologies when they harder to develop for and less user friendly.

    if they think iphone and android are emerging, then they are really saying that customized apps are taking over web apps, because that is what the iPhone does, and any other mobile phone app, drag us out of the dreaful browser into a user interface that is customized for that particular applikation. They might also be saying that user prefer specialized tight applications where the user interaction flow is specifically tailored for the use case, instead of feature rich mega apps that can do anything and at the same time nothing.

    I think Microsoft has the idea right, software + services, at least if you interpret it as, the power of the local desktop app with the power of synchronized data across your devices. I think live mesh is a good example of this, however it still has a long way to go.

    Just take this comment field that I am typing in at the moment as an example of how many years backwards we went in user interfaces when the browser somehow became a universal tool.

    If I had click once/webstart apps that synchronized in my mesh with my data and settings, where the UI was tailored for the device I would take that in a heart beat, or anything resembling that over the browser. This is where Silverlight, or WPF for that matter could really make it happen. Flex is, well technology wise similar, but developing for it is considerably harder than for silverlight, the xaml model really shines when you interact with your design people. JavaFX is still lacking too much in tooling.

    Flash, coding in actionscript is really not something I enjoy, it was fun at first, but in the long run what is more fun is being productive and giving your customers new features, not chasing performance and bugs all over the place because some incarnation of a flash player on a particular platform deviced to behave differently.

  3. Yes they are primarily a web shop, which is quite obvious from their technology interest and heavy lean towards ruby or dynamic languages.

    However I hope their assessments are wrong, I believe the web doesn’t need another HTML standard, what it does need is a data model that is open and a rich user experience development model/(at least they like MVC/MWWM =)), which silverlight/RIA(software) + HTTP/REST solves(services). Javascript before type strong C#/.Net/CLI with dynamic escape, is that really a comparison? I know which model will produce working maintainable code for me the fastest and I know more javascript than C#, but enough to know that C# would be my preferred choice (or any proper language…).

    There are many things a browser is still useful for, but a specialized app will win every time. There are so many LOB apps that were converted to web apps and most of them frankly or way below par…

    I don’t know how many time reporting apps (or document reposistories/CRM) I have been subjected too through the years and none yet beat, what we back then thought of as a really bad app, which was made in VB6 12 years ago.

    Share points works, but shines when it integrates into proper apps. (Groove etc), almost bareable CRM.

    Google apps don’t even come close to useful for anything but the most plain things. (Still very useful when you just need plain things!)

    Gmail compared to outlook (or your choice of mail desktop app), heck even live mail beats it in user experience, just try pasting a picture into a gmail. Sure there is a lab addin, but try pasting something in your clipboard. No try the same thing in a silverlight enabled app just fronting gmail.

    I even bet this blog might even be written in live writer instead of a web page editor…

    The desktop is too powerful not to use why waste it as a glorified document reader when we can do so much better.

    The web should be used for what it does best, connect me to my click once update site and haul my data. Google Chrome got it right, too bad it is a browser =)

    I hope more web shops, including Thoughtworks walks down that path and start innovating our UI interfaces.

  4. Speaking of old movies, I’d seen The Railway Children years ago and had completely forgotten about that scene. I enjoyed watching it again this morning on YouTube. Reading a discussion about Windows/WPF/desktop applications vs. the Web is a little like watching an old movie for a third or fourth time. I remember in the late 90s similar discussions about how superior client/server applications were to HTML/CGI applications. But most companies moved from client/server to Web anyway – despite the horrendously limited user interface. So much so that today I often meet AJAX and Flex developers who still believe they should put all their business logic on the server instead of moving some elements of it into the client.

    In 2004 Joel Spolsky wrote an interesting post on How Microsoft Lost the API War:

    It’s a long post that includes this bit about XAML and Avalon:

    “Instead of Win32, we are told, we should now start getting ready for WinFX: the next generation Windows API. All different. Based on .NET with managed code. XAML. Avalon. Yes, vastly superior to Win32, I admit it. But not an upgrade: a break with the past.”

    “Outside developers, who were never particularly happy with the complexity of Windows development, have defected from the Microsoft platform en-masse and are now developing for the web.”

    That was almost six years ago. That’s a long time. Maybe too long. Even for Microsoft.

    In my work I don’t need to write desktop applications at all. At most I need to support people who use Excel. If I need a quick program to run on the desktop – for example to manipulate some data files before uploading them – I’ll either use Excel or write a quick AIR application. All that has changed is that I’ll use AIR instead of Perl because I can create a decent AJAX or Flex-based UI very quickly.

    Google Chrome is slowly changing the browser landscape. Its JavaScript performance is so good that developers can see new possibilities in the not so distant future. And most important, they see those possibilities using roughly the same technologies they use today. Most do not see a need to do anything as wrenching as moving from Win32 to WinFx. Or, perhaps in today’s terms, from AJAX to something like WPF or WPF/E.

  5. It was never particularly hard to write win32 applications, it was and is many times harder to write good web applications, terrible ones are easy though, so I don’t really understand that logic, joel often has good reasons though and even that article is aimed at saying that clients are better off not being implemented in a server stack, javascript is just a hack.

    It is many times easier to produce a good UI in whatever not involving javascript/AJAX/actionscript, flex was in such a bad shape when it came that I am surprised people jump on the AIR train, it is still quite a mess if you ask me, the migration story is slightly off and different stacks come and go.

    Users will likely not agree with you that javascript and chrome is changing anything, if google wave is anything to judge by then we are still years off, it is truly impressive for a browser UI, but it is still sad in comparison with a desktop UI. A normal Silverlight app would beat that user interface easily and it would be magnitudes faster to develop with no real downside, why is that not a win, both for the developer and the user?

  6. Hi Niclas,
    You wrote that “JavaScript is a hack.” I doubt its inventor would put it in those exact words, but he does say that JavaScript was created in a very short time, by essentially one person, under a lot of pressure to ship a product:

    And, anyone following ECMAScript knows that JavaScript has had a lot of trouble evolving:

    But what I may like or dislike about JavaScript, or Adobe’s ActionScript (which is a superset of JavaScript), doesn’t matter very much. JavaScript is the client-side language of the Web and so developers are driven to use it and get what they can out of it – sometimes (as browsers slowly mature) with a surprising level of success.

    You also wrote that “It was never particularly hard to write win32 applications.” In my experience what is hard or easy depends on your experience. If you’ve been working on Windows applications all your life win32 may not look difficult. If you almost never work with JavaScript and see prototype-based inheritance for the first time, JavaScript may look like an abomination. I used to see this sort of personal experience-driven perspective every year when teaching an introductory programming course to New Media students. At first, many students with little-to-no background in programming found development intensely frustrating and intimidating. It didn’t matter if we were teaching Visual Basic years ago or more recently teaching Flash/ActionScript. By the end of term, most of those same students thought Visual Basic or Flash wasn’t so difficult. The same goes for JavaScript/HTML. What you know and are comfortable with at any point in time colours your perception of other languages, APIs, object models, and so on. I first looked at the Windows API starting back with the Windows 1 SDK. I never found Microsoft’s offerings to be very compelling for the work I had to do. For a while Tubo Pascal gave me what I needed with less effort. Maybe that’s why I always get a kick out of reading Tim’s posts about Delphi. Later it was things like Perl and Java – because of the Web. After Turbo Pascal, Windows never showed up on my radar. Of course that’s just my experience.

    Tim’s post reminds us how long the wait for WPF has been. Microsoft, as I think Joel is pointing out, decided not to evolve in a backward compatible way but to start again with WinFX. Now it is 2010 and the new API and tools are finally mature and ready to use. For some developers who must create certain types of desktop applications I imagine that’s good news. But most developers have moved to the Web where they now have a lot of experience and are relatively comfortable. As Joel points out in some detail, the Web is still much more compelling than writing applications for the desktop. That’s not because JavaScript is the best language or because HTML provides a better object model than XAML.

    Joel gives a bunch of reasons why developers moved to the Web. I’d like to add to the list. The Web is based on some simple, easy to get started with, ideas. A simple markup language, a simple protocol, a simple address scheme, a simple scripting language, and so on. Anyone with a text editor could get started doing simple things that can have a global reach. Another reason may be that the Web has been relatively stable. By that I mean that things like HTML, CSS, JavaScript, got out there quickly and are evolving slowly. In other words, a global and open platform, shipping simple things early, and API stability (backward compatibility) beats shipping something technically more powerful and capable for a desktop OS many years later.

    At any rate, even while there is still demand for native applications, most developers have moved to the Web and I don’t see how WPF, or WPF/e, is going to bring them back to a Windows centric API or Windows-as-the-platform. Flash, Java, and Silverlight act more like escape valves. If you need to do video on the Web today you can do it in Flash while you do the rest of your work in AJAX. No one – not even Adobe – are investing much in desktop media players. If you need vector graphics for your finance search engine you can do something similar.

    As long as the Web continues to evolve to provide an increasingly rich user experience – even at a sometimes frustrating slow place – it will continue to be the dominant platform.

    In that respect I think Chrome (and Firefox) do matter to users and developers. They show that the Web will continue to improve. Users are voting for improved JavaScript performance (among other improvements) by taking the time to download browsers that perform better. Developers working with HTML/CSS/JavaScript believe the platform they’ve chosen is going to continue to improve at a manageable pace. So they aren’t going to abandon the Web as a platform.

    In The Railway Children the band stops playing as soon as the conductor realizes there is no one listening. Today there are still people building desktop applications and Microsoft needs to provide a rich and mature API and tools for those people. Now that WPF and WPF/e have matured enough to work as advertised, Microsoft will do what it can to keep people in the audience. Their well financed band will play on. But I think most developers moved on a long time ago and the desktop vs. Web discussion looks to me like an old rerun of a less compelling movie.

  7. I have been through so many technologies through the years, including turbo pascal and turbo C that you mention (it is where I started). I believe daunting or scary never was a word I would have used to describe any of it. Of course I will be influenced by my own experience, but I do my best to learn all technologies that I decide to voice an opinion about. Doing windows development in turbo pascal was hard, doing it in the vs 5 was easy compared to that, but anyhow each to his own. New Media students does not sound to me as if they are supposed to be programming, which is where silverlight would benefit them even more, the XAML model and integration between the UI/Design people and the programmers is really nice.

    Unless you think hurling the DOM model around in javascript is something productive instead of storyboarding.

    All I am saying is that the current way to develop web applications is inferior to the desktop model and any technology that comes along to change that will get my grace. There is whole slew of developers out there today that have never seen anything but the web model and thus create their application in that model, and many times struggling to produce what would be easily produced in something like silverlight with a different but many times approriate model. Just try doing animations or transitions, real time updates (100+/s) and do that in clien side javascript. Now do the same in silverlight and you are done before the javascript guys have grocked the document model enough to animate.

    I am not talking about what is, I am just stating that javascript is a hack, it is a language that causes more pain than it solves compared to using a proper language. Silverlight is not an escape valve as much as it is a gateway into a world where you can chose the right language for the job, be it ruby, C# or what you may want. AJAX and javascripts are still hacks, the web is and has always been server driven, same goes for javafx or course, flex/AIR not so much.

    Sadly though, the discussions are more religious than techonically interesting, for some reason a big bunch of the world has decided that anything coming out of Microsoft is inherently bad and anything coming out of google is inherently cool.

    Nor am I saying you should abandon the web as a platform, just that we should get proper development model in the client that are as good or better than server side. Separate the concers, model data on the server, model UI on the client, it is better for everyone instead of having mixes such as ASP MVC, Ruby on rails, grails well choose your pick of a framework you have used.

    The first real application we chose to develop in silverlight was truly eye opening, try it, it is easy to forget what you are missing.

  8. I also come from a win32 (Delphi / .net C#) platform, but our current software is being replaced by software made by using a html/javascript/css frontend, ( C# backend). At first it was difficult to get to grips with these new technologies, but using one of the great javascript frameworks (ExtJs), you can get a user interface which is as rich as a win32 user interface! So Niclas go have a look at the examples at at you will be amazed what you can achieve using javascript.

  9. Hello Rob,

    I never stated that you can’t produce UIs that look similar, what I am saying is that the development model is harder, its tools, such as debugger and memory profiling is tougher. Performance is also harder. Now that said I have not used extjs myself only heard about it, but it does like nice. I wonder what the support is for offline mode, but since it is, what it looks like, based on GWT, which actually does provide some useable tooling support, it might support gears (and in the future as GWT support HTML5, HTML5 offline storage). How does unit testing work in ext.js, gwt has support for this too?

    I still cling to my previous assessment, you are often amazed when you see a javascript client side UI, not because it is so great, but because you never thought it could be done in a browser, because all you have seen are more or less bad web pages based on forms. Now I can’t of course speak for everyone but that is my own experience. But when you actually compare it to a rich desktop application (also done right of course) it is still behind, often by a lot (both in functionality and tooling support). Properly working clipboard functions anyone?

  10. Developers have good reasons to be frustrated with developing for the Web. Even WPF developers lose a lot when they move to Silverlight. For example, try to do something that should be simple like displaying HTML formatted mail with embedded images in a Silverlight-based mail reader.

    But over a billion people expect that applications will simply and securely work inside any Web page they visit. They expect to be able to book a hotel room, update financial records in their finance system, watch video, and play casual games without installing anything other than their browser and a plugin or two. You can’t seriously expect them to install desktop applications to do very many of those things for very many of the places they visit on the Web.

    Of course we know that browsers aren’t as secure as they should be, but the desktop is not an alternative.

    Over the years, plugins have acted as a kind of escape valve for developers. If you couldn’t do something in HTML/JavaScript/CSS you could always do it in Java or Flash. But during that time developers found, that with minimal help from Microsoft, they could still make progress at doing more and more with Ajax.

    I think they have proven that Microsoft was wrong to ignore HTML/CSS/JavaScript as an application platform for so long by moving so many people from the IE team to work on Avalon. But Microsoft seems to have believed that the Web was not good enough and would not keep getting better.

    In that respect there is a wonderfully informative interview with Michael Wallent here:

    I highly recommend watching the whole thing from beginning to end. But, here is a short snippet where he compares what you can do with Dynamic HTML (in 2006) to WPF on the desktop:

    “There is some ceiling they are going to get to, that is the maximum functionality they are going to get to … I kind of think about it as the line between content consumption and content creation.”

    “I think that’s really the bright line…”
    Later he talks about keeping WPF/e small and what Microsoft won’t do in WPF/e. One example is the ability to reflow text:

    “There’s only so much code you can fit into that. We think flow text is more than just bottomless flow. You need to do things like pagination, you need to do things like hyphenation and justification to get that nice bright edge… It turns out those are really expensive features…”

    Since 2006 the ceiling he refers to hasn’t been found. Adobe added a better JIT to Flash in 2007, complex text handling including reflow, hardware accelerated graphics, and limited 3D support to Flash player 10. Chrome added threads, improved JavaScript performance, and Google is experimenting with native code. Firefox and Safari performance is improving as well. And, more recently, new Silverlight features appear with each release.

    It turned out that there was no clear bright line between content consumption and content creation. There are things you can’t do in a Web page that you can do with a desktop application but the list is slowly shrinking and for most developers that progress is good enough.

    Now that competitive (and other pressures) have driven Microsoft back to improving Internet Explorer we may see the ceiling rise a little faster. And that’s good because a billion or so people will likely prefer thousands of mediocre Web based applications to installing thousands of desktop applications.

  11. I totally agreed with what Niclas Lindgren has said. As a web developer most of my life, I really hate it whenever I need to spend time focusing on non-core issues such as the stateless mode of http or limits of browsers/html. However, I still develop web aplication whenever I can because I don’t want a company has too much control in IT industry. If today every single computer is a Windows machine, then we don’t need any web technologies. We can just use WPF/WCF and click once deployment and we can deliver easy-to-use software with superb GUI design. Since everybody has .NET framework, all the downloads can be minimal.
    But I don’t want to see that unless Microsoft release the control of platforms (Windows + .NET) to a standard body. People still use http/html/javascript because they are confident that they won’t be screwed by a single compaany. Portability is another major factor, of course, but portability doesn’t just belong to http; as long as we are all Windows, we can then have portability as well.
    If today Windows + .NET technologies IPs belong to the public, we will see the software world like what Nickas has dreamed.
    But for now, as long as the web platform can satisfy my demand, I will just keep using it and I am willing to give up on usability. This is purely business reason, not religion.

  12. After watching the iPad announcement I started thinking about this conversation. It appears the iPad doesn’t allow any browser plugins. You must write native applications if your application needs to do more than what Safari’s HTML/CSS/JavaScript provides. No Silverlight, no Flash, no Java etc. Apple wants you to use their development tools and enrich their platform. So its back to native applications and the desktop. In this day and age of competing virtual machines, who would have thought that would happen?

  13. So its back to native applications and the desktop.

    I don’t agree. Well, clearly there is still a big role for native on Apple’s iPhone/iPad platform. But look what Google has done with Voice on the iPhone.

    It’s not the end of RIA. It’s a drive towards Ajax rather than plug-ins, but the end result will be no different.


  14. Hi Tim,
    I don’t use it, but I assume Google Voice lets you listen to audio messages and send/receive text over http. Basically, it is a voice mail system? If that’s right, it looks like the heavy lifting in that application is largely on the server side where voice-to-text conversion and other phone system related services are implemented. (Am I wrong about that?)

    Now, let’s say you want to build a mobile application where you can leave a new audio greeting or reply to a message with an audio message? Can you do that today on an Apple mobile device using Safari’s support for HTML5? Or, let’s say you want to stream video via IP Multicast on your corporate network so everyone can watch corporate events without loading down your WAN with unicast streams. (This is a fairly common practice.) Can you do that on Apple’s mobile platform using Safari/HTML5? You can do both things with plugins today. So my point was that if your application needs to do more than what HTML5 provides today, Apple won’t let you use plugins to get there. You have to write native applications.

    At the iPad launch I didn’t see much emphasis on HTML 5 applications for the iPad though I don’t know how YouTube for the iPhone is built. Maybe that’s one? The emphasis for developers seemed to be on native iPad applications from the New York Times, Electronic Arts and so on.

    The iPad announcement changed my perspective on Apple. Without more information it’s hard to say, but I think a 1 GHz system ought to be able to run plugins when the user requests it. (They don’t have to run by default.) By leaving plugins out it really looks like Apple is attempting to drive developers to build native applications – especially for the iPad. In that sense it’s “back to native applications and the desktop.”

    But, maybe I’m missing something?

    Yours truly,

  15. By leaving plugins out it really looks like Apple is attempting to drive developers to build native applications – especially for the iPad.

    Brian, clearly Apple is attempting to do that. And it will succeed up to a point; but it won’t significantly damage the web IMO.

    It is interesting to watch, since Apple is getting even more pressure over lack of Flash support than it did with iPhone. It is having to weigh lost sales from people who don’t think it offers the “full web”, against the benefits of control (which include better performance and reliability).


  16. Tim writes: “but it won’t significantly damage the web IMO”

    I’ve been turning that phrase over in my head a few times since I read it. What does it mean to damage the Web?

    I remember when I first saw Java applets. In 1996 they were amazing. One in particular captured my imagination:

    That visual step-by-step proof of Pythagoras’ Theorem seemed to make the case for what the Web could do for education better than all the academic papers I’d read on the subject. Now let’s say the iPad becomes wildly popular and, through each new release, becomes more and more powerful. Let’s also assume that future versions do not support plugins.

    For its users – especially the ones that adopt it as a primary way to view the Web – Jim Morey’s work will have been effectively erased. So will lots of other content that people will choose not to recreate using Apple’s preferred technologies. I’m still trying to think through all of this, but right now it strikes me that there is something deeply wrong with effectively eradicating content by making it impossible to load the software you need to experience it.

  17. Brian

    I agree it is a concern. The difference between then and now though is that the browser itself is more powerful. Thus I see the iPad as more about shifting the balance towards what you might loosely call “HTML5” or “Ajax”, than shifting the balance back towards native apps. That’s why the Google Voice example is interesting.

    The point of interest is whether Apple will gain or lose overall with its no plug-in policy.

    Thanks for highlighting the issues.


Comments are closed.