WinRT : My First Impressions

So I have just finished doing my 1st WinRT demo article (and yes it is for an article for codeproject), which I will have up soon. Coming from a place where I was working a lot with WPF I thought it might be a good idea to capture some of my thoughts/current gripes when working with Win8/WinRT.

I have tried to be as pragmatic as possible, and view WinRT as a v1 thing, which will (hopefully) get better in time. That said there were certain things I just missed a lot. I think what I will do is just list some of the things I found lacking when I was doing my little demo app, and then I will talk about how I found the whole Win8/WinRT ecco system.

Some Of The Issues That Bugged Me

So here is a list of things that I found a bit odd/off, now that is not to say that these will not get fixed, but they still bugged me all the same

XAML Issues

  •  DependencyProperty system, looked far less able when compared to WPF
  • On more than 1 occassion I found that my ComboBox ItemSource Binding must appear before SelectedItem Binding in XAML if you want SelectedItem to populate correctly from the ViewModel (this seemed to be a problem in 8.0 at least), also I believe I have seen this bug before in days of old in both WPF and SL
  •  No binding in setters within Styles (even SL has this now in  SL5). This one needs fixing like NOW. Its plain wrong, and the work around sucks
  •  RelativeSource binding is far less able when compared to WPF
  •  Visibility is lacking “Hidden”, which is actually useful
  •  No DependencyPropertyDescriptor
  •  Can’t do BasedOn style that allows you to BasedOn default style  (or maybe I just didn’t know how to do it)
  •  No x:Static markup extension. This is extremely useful for binding to singleton instance (which I use for all my ValueConverters)
  •  No x:Type markup extension
  •  No custom markup extension
  •  No DynamicResource markup extension
  •  No VisualStateManager.GoToElementState(..)
  •  I may be wrong on this, but didn’t seem to be able to have nested VisualStates one for top level control, and then some for some inner control.
  • WebView is still 2nd class citizen, in certain scenarios its still ALWAYS on top.
  • ListBox backgroundColor / BorderBrush do not work that well with Focus, you have to restyle either whole control or ListBoxItem (container) taking into account Focus VisualState (I think this is a pain others probably disagree)

Decision Issues

  • No DatePicker control (ok its coming in 8.1, but please what the heck, do people not need to amend/pick dates in Windows 8. This is plain lazy)
  •  No Triggers in Styles/DataTemplates. Follows the SL model of VisualState(s). In my opinion (and I am not alone here) Triggers are and ALWAYS will be more powerful than visual states. At least give us both and let us use which model we prefer
  • No Blend interactivity interactions. My god so we are now back in WPF v1 land where we have to right our own attached behaviors for everything. Practically any XAML developer will have become accustomed to using the standard Blend interactions / behaviours. We want these back.

Plain Weird Issues

  • Enumerable.Range(2013,2023) plain doesn’t work. Try that and see what you get. It is very odd
  •  DateTime object is very limited compared to .NET version

What Was The Win8 Ecco System Like To Use

WinJS or C#

Now as I have stated I am predominately involved with WPF, I do however also do a fair amount of ASP .NET MVC /  and MVC/MVVM client side Javascript development (Knockout.js / Angular.js / BackBone.js). So what language did I pick when doing my Win8 article. For me that was a no brainer, C#. Too be honest I find the whole idea of a bastardized version of Javascript that will only run on Windows8.* completely alien. If you believe the press, its plain JavaScript. Sure it is.

The other thing I just don’t see it as a very transferrable skill (oddly XAML is, its in WPF / SL and now WinRT). For example if I used just WinJS every day, do you think that would be a transferrable skill, cos I sure don’t. Lets say I was doing TypeScript or native JavaScript would they be transferrable skills, well yes they would. C# on the other hand, still very much in vogue if you ask me. So that 1st language choice hurdle was an easy one for me to make.

Others may strongly disagree, but that was just my take on it.

App Structure

I have to say I am not mad keen on the overall application structure. I mean have you seen how much boiler plate code you get in App.xaml.cs, here it is for a new project. Thats nasty if you ask me:

/// Provides application-specific behavior to supplement the default Application class.
sealed partial class App : Application
/// Initializes the singleton Application object.  This is the first line of authored code
    /// executed, and as such is the logical equivalent of main() or WinMain().
    public App()
        this.Suspending += OnSuspending;

/// Invoked when the application is launched normally by the end user.  Other entry points
    /// will be used when the application is launched to open a specific file, to display
    /// search results, and so forth.
    ///Details about the launch request and process.
    protected override async void OnLaunched(LaunchActivatedEventArgs args)
        Frame rootFrame = Window.Current.Content as Frame;

        // Do not repeat app initialization when the Window already has content,
        // just ensure that the window is active

        if (rootFrame == null)
            // Create a Frame to act as the navigation context and navigate to the first page
            rootFrame = new Frame();
            //Associate the frame with a SuspensionManager key
            SuspensionManager.RegisterFrame(rootFrame, "AppFrame");

            if (args.PreviousExecutionState == ApplicationExecutionState.Terminated)
                // Restore the saved session state only when appropriate
                    await SuspensionManager.RestoreAsync();
                catch (SuspensionManagerException)
                    //Something went wrong restoring state.
                    //Assume there is no state and continue

            // Place the frame in the current Window
            Window.Current.Content = rootFrame;
        if (rootFrame.Content == null)
            // When the navigation stack isn't restored navigate to the first page,
            // configuring the new page by passing required information as a navigation
            // parameter
            if (!rootFrame.Navigate(typeof(GroupedItemsPage), "AllGroups"))
                throw new Exception("Failed to create initial page");
        // Ensure the current window is active

/// Invoked when application execution is being suspended.  Application state is saved
    /// without knowing whether the application will be terminated or resumed with the contents
    /// of memory still intact.
    ///The source of the suspend request.
    ///Details about the suspend request.
    private async void OnSuspending(object sender, SuspendingEventArgs e)
        var deferral = e.SuspendingOperation.GetDeferral();
        await SuspensionManager.SaveAsync();

Coming from other stuff like there is a lot less clutter in the main entry point.

The other thing I really didn’t like is the way you had to have this special ResourceDictionary called “StandardStyles.xaml“. If they truly are standard, what the hell are they doing in my app, and why aren’t they included in the framework. Also why are most of the styles in there commented out, and we have to uncomment them as we need them.

Magic Classes That Are Provided

I also didn’t like the fact that there are a bunch of classes provided which I have no idea whether I need them or not.

For example if you create a new Grid application you get this.

  • Common
    • BindableBase
    • BooleanNegationConverter
    • BooleanToVisibilityConverter
    • LayoutAwarePage
    • RichTextColumns
    • SuspensionManager

Now I know what a value converter is, so they are ok, but don’t things like “LayoutAwarePage” and “SuspensionManager” sound like framework issues to you? They sure do to me, again why are these classes in my codebase. Surely a LayoutAwarePage should be the defacto page for ANY WinRT application. You know we are supposed to think that the Surface is an iPad rival, yet last time I looked I could twist an iPad this way and that, and you can also do that with a Surface. So why isn’t the LayoutAwarePage the standard. By the same token since there is a suspension type of lifecycle in WinRT why is the SuspensionManager not in the class library.

Also what the heck is “RichTextColumns” do I need that, what does it do. Is it required for a GridView, and if so (yes I’ll say it again) why isn’t it in the framework.

Ok, I could find out, but when I start a new app, I would much prefer to see a clean slate really.

Early Days But

To my mind it just feels like it was rushed out the door, and feels very unpolished. Now I am a massive Microsoft fan boy, but I just felt let down by WinRT. As I say I will still be putting out this WinRT article soon, but it will likely be my one and only for a while.

Anyway those are just my thoughts, no one elses, many will likely disagree, which is fine.



  1. I’m glad to see I’m not the only one not satisfied with WinRT… I’ve been using WPF for years, and it’s a really awesome platform, so I expected WinRT to take advantage of the WPF experience. Instead, when I write a WinRT app, not an hour passes without me bitching at the lack of this or that feature… It is very frustrating to feel so limited by the platform.

    I agree with you that classes like LayoutAwarePage should be in the framework itself, it just doesn’t make any sense to have them in your code. Especially when you migrate an app to 8.1 and you need to edit the LayoutAwarePage in all your projects…

    Another pain point is error handling. Very often, I get exceptions in the App.UnhandledException event with no details at all, not even a stack trace. All I get is a HRESULT (I had thought we were rid of those, but apparently I was wrong), and a brief, not very helpful message if I’m lucky.

    On the whole, WinRT doesn’t seem to be really finished, it feels more like a draft. Win 8.1 brings many improvements, but it’s still very far from being as good as WPF…

    On the bright side, I really like the omnipresent async model. It makes it really easy to keep an app responsive.

    By the way, you can use behaviors in WinRT. This Nuget package


      1. Actually yeah I did come across this before, but I wanted to remain angry at this platform for a bit to get this blog post off my chest. Hopefully it will improve

    1. A lot of your gripes have changed in 8.1. Not saying they’re fixed, just changed ;). LayoutAwarePage and StandardStyles.xaml are gone. Which really just means you have to roll your own, as layout functionality still isn’t in the framework. They just punted since now your app can be any size when snapped. Yes, the templates for Win8 apps are horrible, with lots of things that really should be in the framework but instead are crapped all over our solution in very hacky fashion (have you looked at the code in LayoutAwarePage that determines orientation?). Heck, even the name LayoutAwarePage is horrible, because (not following SRP) this class deals with non-layout concepts like page navigation. WTF?

      I’ll be quite frank… I never found Silverlight to be much better. Silly compromises were made in the name of compactness. An ICommand without a command source? Behaviors eventually stepped in to deal with this deficiency, but still. It took 4 versions of Silverlight before we had something usable, and it still was a very poor substitute for WPF. WinRT has such huge promise, as it’s not .NET based, but right now WinRT is almost as bad as Silverlight 1.0 was, which means we have 3 more versions to go before it’s “OK”, and it still won’t be as capable as WPF.

      I’ve done enough WP development that I can live with it, but it is depressing that since WPF was released for every step forward we’ve made, we’ve made at least 5 steps back. Instead of fixing the things that needed fixing and adding the things that needed adding in WPF, Microsoft has spent the last 5 years reinventing the wheel, twice. Each time worse than the last. Yes, the promise for the future is still there, and I believe in the end game goal, but it’s getting to the point where I fully understand why people don’t care to wait around for the future promise. Microsoft is making mistake after mistake and are alienating their dev community (developers, developers, developers my arse). They need to turn this around, and quick.


      1. Bill thanks for your great reply there. I could not agree more with everything you have said. I honestly like XAML (you know this), but just wish it was based more on WPF ideals. Grrr. Anyway thanks for your comments. Appreciate the time you took at post them.

    2. You are certainly not alone here. I had also forgotten about the unhandled Exception with no meaningful error message. Seen that too many times, guess I am used to it already.

      +1 for WPF being awesome, its still by far the best platform in my opinion. Thanks for your comments.


  2. Im glad I put XAML behind me and switched to Qt – a GPU accelerated cross platform C++ 11 API with a Javascript DSL (QML) – used to build Google Earth, Skype, & now WireShark.


    1. Sadly I don’t know C++, and now feel its too late for me to learn that to be at the same level of ability I am with .NET / C#.

      I have seen Qt before (trolltech) right. Picassa desktop app was written in it too.


  3. I produce enterprise level applications used in the healthcare arena. I have been a huge Microsoft fan in the past. WPF was great, but it did entail installing client side s/w. We embraced SL (as of SL3) and thought of it as WPF/E (even if there were weird restrictions/decisions and a different markup). However, with WinRT & WinPhone Microsoft has made it a totally non useable platform for enterprise clients (it takes the worst attributes of WPF in that client code needs to be installed and it offers a user base of zero percent (in my world)). I have no choice but to migrate my client code to be browser based. It feels like a huge step backwards, but a step that has no good alternative.


    1. Mark

      Yep I feel the pain. We are a Microsoft shop, but also do lots of dev work with ASP MVC / MV** Javascript libraries. I love WPF. But alas Win8.* is a sad thing. It gets even worse for the enterprise devs, the sideloading story is plain madness. It just alienates pretty much most devs from using it. Microsoft have really lost it with this one.

      A) The platform right now, is plain rubbish
      B) The licensing is madness
      C) The installation guidelines are utter madness too

      Karl Shifflett has a good post on this :

      Also at the end of Karls post is some stuff from another industry heavy big wig (Rocky Lhotka). I trust both Karl and Rocky a lot, their comments carry a lot of weight with me.


  4. I really don’t get why you write an article about WinRT in Windows 8 when Windows 8.1 is already released. This new version addresses many of your complaints. You’re a year too late, man *sorry*.


    1. I only had windows 8 available. And I was oh doing it to give winrt a look really, but yeah valid point. I think much of the stuff in the article is still totally valid though. It’s just layoutAwarePage has gone really and standard styles has gone. Other than that same really.

      But yeah I take your point. Truth is I think I’ll be sitting this one out until windows 8.9 by which time it may actually be usable


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s