I hear about WPF, Silverlight but then there is also windows RT, metro stuff, windows 8 and so on at the moment - I'm having a hard time nailing what to bet on.

How do I, at a given point in time, find the best platform for doing somewhat future-proof GUI?


Looking at the current trends at Microsoft, you cannot future-proof your UI if you tighten it to a given framework. You need some abstraction to make your application future-proof, and there are good design patterns for that (see Model-View-Presenter and Model-View-ViewModel).

If you do not need tight control over how things look exactly, you can have a generic UI framework like wxWidgets, QT and SWT or a framework that helps you to avoid too much binding to your UI framework, something like Caliburn Micro.


How do I, at a given point in time, find the best platform for doing somewhat future-proof GUI?

INMO, this is a desirable goal but neither realistic or well defined.

It is not well defined because you really should quantify the 'future' part. It is not realistic because history tells us that GUI technologies are the fastest to change, and their changes are radical.

Back to your question, one needs to see why this is important in real life applications. You see, even older technologies are not always dropped suddenly and the live for a long time. Control vendors are still providing upgrades to Windows Forms application GUI components. You can develop a touch-based application today using Windows Forms. Something you probably can't do with native out-of-the box newer Silverlight!

The first thing I would do is to decide on your expected user environment. Next, I would identify the types of devices that the application must run on (applets, mobiles, web, desktop, etc.), then you check the supporting languages and tools.

WPF and Silverlight will still live, though may not be the magnet for improvement dollars. XAML, in some form, will be used in the Windows 8 world. if you think along the Silverlight path, then check the System Requirements matrix on MS-Silverlight.

Developing an application that is not dependent on the GUI, does not sound very realistic for many commercial business applications at least. The extra complexity is very difficult to justify. What business people sometimes tend to find is that the technology outlives the business model some applications are built on. (I remember a project we did for a large bank that lived for 3 months only because another bank acquired the one we did the project for :)).

If you are heading in the web direction, you may want to consider HTML 5 and JavaScript with 3rd party controls. There are good ones evolving these days.

Good luck.


The answer of all answers: It depends

When you are developing a application you have to make some decisions:

  • Should it be a Webapp ? (aspx for example)
  • Should it be a Desktop App?
  • Which system do use my users?

etc pp.

So in this point you can think about abstraction. Encapsulate your pure logic in different assemblies and build only a UI Layer on top. In this way you can use different UI-Strategies.

But seriously: When you want to develop for Windows 8 be sure that the .NET 4.5 and the Windows RT has some difference to .NET 4.0 which is runable on XP, 7, Server ect. pp. So it is up to you and your customers which UI you are going to develop.


There are too many aspects to consider: your customers needs, the permissions you want to have on a system, the UX feel you want to give to your app, etc.

  1. Metro apps are great for touch¹ and great for full-screen single application user experience. You can have several valid reasons to do a Metro app:

    • 2D game like BabySmash,
    • A basic, single-tab, web browser which will mostly be used to access one or few websites (read the e-mails and go to Facebook) or a single website (kiosk mode),
    • A kiosk app,
    • Very technical and specialized apps for very specialized employees. For example, a multitouch Metro app is great for system monitoring where you can zoom on graphs, switch to more detailed visualizations by taping on thumbnails, etc. Note that in this case, the application remains always on, since the machine is intended for monitoring only.
  2. Silverlight is great for:

    • Apps which cannot use HTML 5 (for the reasons of compatibility with legacy browsers) or they must use some features not available in HTML 5,
    • Apps to use inside a company, which doesn't require lots of permissions or a strong integration with the company infrastructure (accessing Active Directory? Printing something with no action from the user? Writing to shared folders?).

    In both cases, the great point is that system administrators doesn't have to deal with installing/keeping secure/updating tasks related to your app.

  3. WPF applications are great for everything else. If you need strong integration or additional permissions and if you know that your app will be used as a business app, side by side with others, in a daily work with no touch, go for an ordinary WPF app.

Don't forget about HTML. If your customers are non-technical people who will be never unable (or want to) install additional software, update it and maintain it without third party help, or if your customers use MacOS and would not run Windows on a virtual machine just to use your app, don't go with Metro/Silverlight/WPF at all. You have to use plain HTML/XHTML. It may either be HTML 5 if you know that 95% of your users will support it, or an older version if not. Flash is a solution too, since it's popular enough to be installed on most computers.

¹ It's not because they are Metro apps that they are automatically great for touch. You, as a developer/interaction design expert, must know how to implement efficiently the touch/multitouch to your app. Nothing is more annoying that an app which is intended to be multitouch and which does it totally wrongly (being at the same time unusable with mouse and/or keyboard, because the developer doesn't care that some people still use those input devices).


You do not. You write your code logic such that the GUI layer can easily be replaced with a different one -- code to an interface not an implementation. As @Max states in his comment, this indeed does not need to be in your application language as long as you have a way to call it from said application.

As far as framework go, WX widgets could be useful as an example of how others have done a GUI that wrapps different implementations. I am not suggesting that this is the one you should use.

  • 1
    I don't think interfaces generally work between Silverlight and C++ Metro.
    – DeadMG
    Mar 30 '12 at 8:18
  • I'd almost upvote for most of the first paragraph but can't because of the second
    – Murph
    Mar 30 '12 at 8:48
  • @DeadMG To be fair, he doesn't say that the interface needs to be a language construct. If you interpret it to 'C interface' for example the library will be callable from almost every language out there. Other interfaces are also available, of course.
    – Max
    Mar 30 '12 at 9:05
  • @Murph: care to expand why WXWidget is a bad choice? It is a wrapper to other GUI frameworks and as such would use a lot of concepts that svrist could apply to his own code. I was not suggesting he used that, just as an example of how others have done a GUI that wrapps different implementations. Maybe I was not clear enough. Mar 30 '12 at 9:15
  • @Sardathrion well you've edited the answer... but: "wxWidgets is a C++ library" which would not be my choice for windows dev and I believe that if you're talking about windows development then you're better off just grasping the nettle and developing an understanding of XAML
    – Murph
    Mar 30 '12 at 10:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.