This article is more than 1 year old
Pity the poor Windows developer: The tools for desktop development are in disarray
A Microsoft posting reveals deep-seated issues
In need of a roadmap
A recent post by Microsoft’s WPF team, and the comments it provoked, has revealed the unhappy state of Windows desktop development. Presented as a roadmap, the post promises investment in WPF to improve performance, DirectX interoperability, tooling, and support for touch input and high density displays.
While this seems welcome news, it is not really a roadmap, and the ensuing discussion brings up numerous issues that Microsoft seems unlikely to fix. For example:
“Really? This was what you think your users are desperate for? How about "not making it buggy as hell on different graphics cards", or maybe just something as simple as bringing the capabilities of the controls up to par with what we had in WinForms? Maybe do something with printing so that it doesn't turn into a dark art based upon off-screen rendering of XAML controls that change with each minor .NET release (which are now in-place upgrades, thereby breaking your clients' apps when they install a simple update). While we're on the subject of printing, perhaps either push XPS as a viable technology or abandon it for the half-dead animal that it already is.”
WPF is the best available option for many scenarios, but needs a lot of work to bring it up to modern standards, including a revamp of XAML and its styling system (as noted by some commentators). The difficult learning curve is another problem; fixing this properly would involve changes to the tools as well as the framework, but with Microsoft’s main focus elsewhere that does not seem likely.
Despite the promise to support touch input, which is important now that Windows tablets are commonplace, this critical bug report regarding touch support has the comment from the WPF team: “We appreciate the feedback. However, this issue will not be addressed in the next version of WPF. Thank you.” That said, during the writing of this post and following a Twitter enquiry, Program Manager Harikrishna Menon said on Twitter that "the Connect issue is still active and we are looking into fixing this for a future release of WPF," evidence that Microsoft is changing tack and giving at least some higher priority to this framework.
Should WPF developers switch to Universal Apps? There are several reasons why many cannot. One is that unless Microsoft back-ports the Windows Runtime (which supports Store apps) to Windows 7, Store apps will not run on the version of Windows most used in business. Another problem is the immaturity of the Store app framework versus what is possible in desktop Windows.
Microsoft has recently published much of the .NET Framework as open source, via the .NET Foundation, but to the frustration of desktop developers this does not include the Windows desktop frameworks.
This leaves Microsoft in the odd situation of giving developers no fully satisfactory framework for desktop applications. Much is either old, or broken, or difficult, or all the above. What is on offer is good enough for quick business applications, but those who want to get the best out of the platform have a hard road ahead.
One answer is that this is now the wrong place to focus; developers should look at web, mobile and cross-platform instead. Indeed, this is one reason (along with Microsoft's constant changes of mind) why the desktop resources are in disarray. The response to the WPF “roadmap” demonstrates though that a substantial number of developers do still find value in Windows desktop applications, so perhaps Microsoft should do more to support them.®