Friday 18 June 2010

What is wrong with WPF?

In 2007 I attended a Microsoft sponsored event for the UK's Visual Basic User Group. Now, I am not a VB programmer and never have been, but this group is open minded enough to allow C# programmers like me in. Anyway, this event was VBUG UK's annual conference and was hosted at Microsoft's Reading campus. During the two day event, Microsoft provided many product evangelists to speak about the wonders of the Windows Presentation Framework (WPF) and Silverlight. Naturally I was impressed. The whole event was carefully designed to impress people like me. No more would I have to allow a quality program to go out to my customers with a 1990's user interface, for that is what Microsoft's Dot Net Windows Forms platform is in essence. I could now get a proper graphics artist in to craft a quality user interface directly in XAML and then get a C# programmer to hook that up to the business logic. My end users will finally get web-like polish, and here I mean gradient fills, rounded corners, subtly animated buttons and other controls... Really it was almost programmer's porn! Microsoft made a big thing about how they were sorry that they have neglected the graphics processor in the PC. Apparently the GPU manufacturers had been hard at work creating ever faster chips with 2D and 3D acceleration, spurred on by a growing home gaming market, but all these business desktop PCs had the same chips in them, that were sitting idle 99% of the time! Finally, Microsoft was going to let us developers write software in Dot Net that utilitised these fantastic GPUs. So I returned to the office full of inspiration and set about redesigning our company's bread-and-butter application to take advantage of all that WPF offered. Along the way, I built many small applications to try out this or that feature, like data binding, animations, custom controls, data access via LINQ (another new Microsoft technology that came along at the same time as WPF). It all worked beautifully, and fast, and used little memory... All the right things a software architect wants to know. I even wrote a few small applications to stress-test the system, and it worked reasonably well. Not as good as Windows Forms did, but then WPF did a hell of a lot more under the hood to make the user-experience much richer. So it was a trade-off I was willing to accept. So we hired two more C# programmers on the spot. Wind the clock forward two and a bit years, and my product is now ready to be unleashed on the world. Okay, maybe not the world, just those companies specialising in building Social Housing in the UK. A niche market really. A market that has evolved over the last three years. A market where these not-for-profit organisations have become more efficient at building more social houses for less grant money. A sector which has wholly embraced virtual server technology and thin client computing. Thin client devices with 128MB RAM running some Linux flavour that boots up in 5 seconds flat and loads Citrix WinFrame or something immediately. Devices that don't have graphics accelerators. Devices that are wholly inappropriate for WPF. So now I have a fantastic application, that cost an astronomical amount of money to develop, that none of my customers can use. Oh sure, it works on their Citrix servers, just very very slowly because neither the servers nor the clients have any graphics acceleration in hardware. Now that I have lifted my head out of the trenches (so to speak, for didn't you know that programming can be bloody harsh like a war almost) and looked around, I find everyone else has stopped developing for the desktop. All the major development is now in the browser. I hear buzz words like JavaScript (again, is this really making a comeback?), AJAX (not again, I thought this died a well-deserved death in 2005!!!), Python (what, from the 1980's?), Google AppEngine, Amazon S3, Amazon EC2 and Microsoft Azure, and so on... So instead of redesigning the wheel like Microsoft did with WPF, it seems everyone else decided just to improve the browser. While Microsoft spent 6 years doing nothing with Internet Explorer 7, the other browser vendors started to implement CSS3, and HTML5. When Microsoft finally woke up and decided that IE was dying, they rewrote large sections of rotten code and produced IE8, the most secure browser on the planet (for about two weeks until the hackers cracked the weak security), also the fastest Microsoft browser ever (still 25% slower on most tests than Google Chrome), and supporting five features from the HTML5 draft specification (okay, most other browsers support well over 90% of the HTML5 features). And I am wondering not so much what is wrong with WPF, but when has Microsoft lost the plot? Was it when Bill Gates semi-retired a few years ago? Was it when he completely retired? I'm shocked. I have always been a Microsoft fan boy, and wouldn't have anything to do with Apple or Unix. Novell, Sun, IBM and Apple have always been the big bad greedy bunch in my eyes. But in 2001 I got an iPod for a Christmas present. Right off the bat I had problems with it -- it was made by Apple after all, and required me to use iTunes on my PC instead of Windows Media Player (my favourite). The iPod itself was fine, it was iTunes that I hated. Not just me, apparently, too many other people complained about iTunes, and it has been improved tremendously over the years. It is now my favourite media player. Maybe because I now have an iPhone in my pocket, another iPod that permanently lives in my car, a little one I take into the gym with me... And I now have an iMac at home on which iTunes really shines. It turns out that the problems I had with iTunes was really just down to iTunes not finding support in the Windows operating system for things that were supported in the Mac OS. So Apple is still very greedy in my eyes, but I love the quality and intuitive usefulness of their products, which is a trade-off that I am willing to accept. My own company's email had been moved away from an in-house Microsoft Exchange server, into Google Mail (Premier Apps), and I must say, it has been a vast improvement. It turns out that Email is not really an application that should be hosted anywhere but in the cloud. Really, if you think you can host it on-site, think again. You are just wasting your time and money. Back to WPF. Surely if my customers have such light-weight client devices that can't run WPF, then they will also struggle with rich web 2.0 applications? Yes, at the moment they do. But, Citrix (and VMWare) are working on improving the remote desktop protocol to allow smoother animated web browsing in thin-client setups. They are not working on speeding up WPF though, as that is a proprietary Microsoft technology, and the problem is not that Citrix or VMWare don't want to improve this, it is just that Microsoft sees them as competitors to their own Windows 2008 Application Streaming product, and therefore won't cooperate. So how about Windows 2008 Application Streaming. How well does that do in thin-client setups? There's only one way to find out, I said. So we bought a new server and installed Win2008R2 in application hosting role. We bought a couple of Windows XP thin client PCs (a lot more expensive than the Citrix/Linux versions) and upgraded the Remote Desktop Clients to version 6 and did some WPF testing. Need I tell you the results? No, I'm not going to depress you any further. Even if I could persuade all my customers to upgrade their two-year-old thin client PCs to Windows versions, they will still not ask me to slow down my application's user interface. So what really is wrong with WPF then? 1) Memory. Microsoft designed this technology back in the day before they lost the plot, when a dream of Windows on every business desktop (not a thin-client desktop mind you) was a realistic vision. If every user had a PC with 2 or 3GB of RAM, then what's a few megabytes of overhead per form, and a few kilobytes of overhead per control, per style (skin), per template, per language, per colour, etc.? In reality these all add up quickly and once you have built a decent size business application, you need a couple of gigabytes to run just this one application. 2) Graphics. Microsoft designed WPF when each desktop PC had its own GPU under direct control of Windows DirectX. Sadly this is no longer the case. Microsoft weren't the only ones to realise these power-hungry GPUs were not utilised in business PCs! Others noticed it too and decided to remove them completely and scaled down the business PC to just a thin device that is not only green (using little power) but also quiet (requires no fans for cooling). Hey let's all do our bit to save the planet!
3) Speed. Whenever Microsoft launches anything new, it is always slow for a while until hardware vendors rise to the challenge. Within a few months better hardware will come along to make the new Microsoft product work just as fast as the previous Microsoft product (with fewer features). Microsoft designed WPF in an era when Intel and AMD still delivered annual speed increases in CPUs. Sadly they stopped doing that. Instead we now have CPUs with more cores and more powerful cores, that still run at just around 2GHz. The only way to make use of these extra cores is by writing multi-threaded applications. Sadly WPF is NOT MULTITHREADED. 4) Multi-threading. Like Windows Forms before it, WPF is not multi-threaded. You can start up as many background threads as you like to do anything you like, but only one thread (the one started by the operating system when it loaded your application) can touch the user interface. If any other thread tries to add, say, a node to a tree control, all hell breaks loose. This is the most serious flaw in Microsoft's whole Windows graphics subsystem. Of course there are ways around this. But this means using queues (more memory) and timers (artificial delays) and expensive cross-thread dispatching (wasteful in CPU cycles). Not to mention all the extra checks Microsoft have built in. Every time you try to change anything in the user interface, Microsoft first checks to see if you should be allowed to do so -- not a security feature -- just a thread-limiting measure to keep the operating system stable. I have to ask, like so many before me, why oh why can't they make the windowing system thread-safe? Do we have to wait for Windows 11? When that finally happens, will anyone still have an actual PC to install it on? I wonder. 5) Data binding syntax. This is one of the most powerful features of WPF, bat also the most poorly designer, and poorly documented. It's a bit of a black art really, and many good developers make too many mistakes. Expensive mistakes, you know the kind that takes weeks to debug and pin down? Yeah them. 6) LINQ. This is a technology that makes it easy to write data queries in your favourite langue -- C#. No more SQL syntax to mix in with C#, just plain readable goodness. Bah, it only it performed at 10% the speed of a DataReader one could still perhaps motivate its use as a good tradeoff between program maintainability and end-user performance. Sadly, its much worse of a tradeoff. LINQ creates and object instance for each row of data it retrieves, plus collections of these, and uses DataChange events to track changes to these instances. Great, except if you repeat the query, you get a whole new set of objects, and now you have two object instances referring to the same row of data, and they are not kept in-sync! So you end up maintaining your own Dictionary collections of the same instances, which uses even more memory and wastes even more time... Even then, if another user modifies a record on the database server that you already have an object instance in memory for, you don't know it, because LINQ does not implement SQL Server 2005's notification services. Believe me, unless you are writing trivially simple applications where you don't care about other people writing to the same records that you are observing on your screen, you are far better off as a developer to stick to DataReaders and hand-crafted SQL queries. And finally, please don't tell me I have sour grapes. I know that already thank you.