1

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?

Turbo
  • 2,490
  • 4
  • 25
  • 30
  • Do you have any previous knowledge or expertise in any of these platforms? – Federico Berasategui Nov 12 '12 at 19:31
  • The whole "WPF / SL are being dropped" paranoia is to much exaggerated IMO. People here are still writing software in VB6. – Federico Berasategui Nov 12 '12 at 19:34
  • If you plan to migrate this application to WinRT in some point of the future i recommend you WPF or Silverlight as migration will be easier from those plataforms to WinRT, otherwise, go with WinForms, anyway the Desktop will be with us for a long time, as proven by MS-DOS. – Rafael Nov 12 '12 at 19:43
  • @Rafael I don't think winforms is suitable here. "will require a fairly rich client interface". You don't get that in winforms without doing a hell lot of `Override OnRender()` – Federico Berasategui Nov 12 '12 at 19:47
  • @HighCore, you're right i may have missed that part of the question, then just WPF or Silverlight. – Rafael Nov 12 '12 at 19:55
  • @HighCore, I've got a fair amount of experience in WPF and Silverlight, none in WinRT, and a bit around HTML5. But I'm not really worried about my learning curve. I'm mostly trying to determine the best long term strategy for developing new commercial Windows applications, that will require customized rendering of the UI to support visualizations and animations of data. I need a pick platform robust enough for our viz needs, that can go to market within 6 months, yet wont require a full rewrite in 2 years. – Turbo Nov 12 '12 at 20:18
  • It does sound skitsofrantic. "Architect a new Windows application." "Forced to go with a web based approach." Just what is forcing you to take web based approach to a Windows application? – paparazzo Nov 12 '12 at 20:40

1 Answers1

2

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.

Federico Berasategui
  • 43,562
  • 11
  • 100
  • 154
  • "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." words of wisdom. – Yandros Nov 12 '12 at 20:56