I'm starting to architect a new Windows application that will require a fairly rich client interface, but I have no idea what client API I should go with (WPF, Silverlight, WinRT, HTML5, other?). I'm actually rather disturbed that there is so little guidance from MS to help people make this decision.
Whats the MS support strategy for the different client APIs? Whats the longevity for each? I dont want to write a full client application in a currently known and supported API (WinForms or WPF) only to have MS pull support for it in two years, and be forced to re-write it. But I really cant write it in WinRT because mass corporate deployment wont be in place for at least 2 years. So am I forced to go with a web based approach, like Silverlight instead? Whats its support/longevity story? Do I go HTML5 instead? If I go that route, whats the benefit of using the Microsoft stack instead of just going the open source stack?
It feels like I'm in a total catch 22 here, and I cant find any good guidance from Microsoft. From the sounds of things it would be stupid to write software in WPF because its being dropped (soon?), but I cant write it in WinRT because corporations wont deploy it for a couple years. This whole thing just feels completely skitsofrantic to me.
Thoughts or ideas?
Taking your experience into account, and also the fact that you said 'Windows Application' (not web application) I would definitely go with WPF. Keep in mind that regardless of using a different set of underlying APIs, WinRT still keeps the core concepts of WPF: XAML, Bindings, Styles, Triggers, DataTemplates and so on. So, while it is true that you cannot copypaste code from WPF to WinRT and press F5, there is a significant amount of work that would be compatible between these technologies (namely ViewModels that are view-agnostic), while HTML, Winforms and other frameworks have completely different ways of doing things, and require a different mindset to work with.
In regards of what will Microsoft do.. I wouldn't be too worried, because evidence shows that even older technologies such as VB6 still remain "runnable" in current versions of OSes, and I don't think there will be a need to rewrite the whole application in 2 years even if Metro becomes a standard. Metro cannot replace desktop traditional applications, which still prove to be the best option for data intensive applications.
And, if it ever comes the time when all of us are really pushed into WinRT, it's gonna be immensely easier for those who made SL / WPF applications already written using MVVM and XAML, than for those who did HTML or winforms.
Whatever you end up choosing, make sure you separate as much as possible your application's functionality from the UI. This will definitely make it a lot easier when a UI framework change is required.
This is just my personal opinion, and I would like to hear what other people have to say about this subject too.
Edit: Another really important aspect is that if you need to really make an animation-intensive UI, or take a step away from traditional battleship-gray UIs, you're gonna end up suffering a lot from winforms incapabilities on this, or HTML/Javascript hell where all browsers render things differently, not to mention the amount of code required in these technologies to achieve things that require 3 lines of XAML in WPF / SL / WinRT.