As of last week I assumed management and content development for the Windows App Builder’s Blog, which I’m sure most of you follow already.

What I’d love to hear from you is this: what content would you like to see on the blog? What questions are you dying to have answered? What ‘inside stories’ from the Windows engineering team would you like to know? Let me know in the comments!

As I’ve had occasion to look at more C#/XAML code lately, I’ve noticed a common pattern around the await keyword. Make no mistake: await is a marvelous language construct that makes it super-simple to write code using async APIs that otherwise looks like synchronous code:

private async Task<[type]> MyFunction()
String result1 = await Operation1();
String result2 = await Operation2(result1);
await Operation3();
return [something];

Once EcmaScript6 is adopted in the app host for Windows Store apps written in JavaScript, we’ll see the same thing in that language as well.

What’s important to remember about await, however, is that it’s not always necessary. That is, if you simply need to start an async operation but don’t need its results right away, then you don’t need to stick an await in front of it and block the current thread. That is, you don’t want to force synchronous behavior where it’s not actually necessary, allowing instead for some operations to run in parallel.

In the code snippet above, for instance, we clearly need to wait for Operation1 to finish before invoking Operation2 because we need result1 as input to Operation2. Operation3, however, is not dependent on Operation2 at all, so it can clearly be running while we wait for Operation2 to finish.

In addition, because we’re not returning anything from Operation3, we don’t need to await that one before returning from the function.

Remember that await is just an easy way to avoid writing explicit async structures with an explicit completed handler (as you have to do in JavaScript today), and if you don’t need to do anything with those results, then it’s not necessary to use await at all. (For more background on async and await, see Diving deep with WinRT and await on the Win8 Developer Blog.)

The code above, then could be written as follows to allow Operation2 and Operation3 to run in parallel, along with anything that happens after MyFunction returns:

private async Task<[type]> MyFunction()
String result1 = await Operation1();

String asyncOp = Operation2(result1);
asyncOp.Completed = delegate(IAsyncOperation<String> result2, AsyncStatus status)
if (status == AsyncStatus.completed)

return [something];

It’s more code to write, but will generally make for better performance in your app.



We purposely included many talks at //build 2013 about performance because it's one area that's very important for all the apps you're creating as well as for consumers' overall experience of the system. Windows 8.1 Preview has better performance across the board, so in many ways apps just benefit without doing anything special. Then we're introducing more tooling around performance, and have more experience now at best practices for apps.

Here's a rundown of the perf-related talks from //build. Pick and choose those that are relevant to your chosen language and presentation layer:

General (including reliability):




(Thanks to Brendan Clark for this explanation)

If you have a XAML app in snap view that starts and animation, and then switch to another view state while that animation is running, elements like a Shape can become very blurred. The reason for this is that Shapes are realized/rendered at a specific scale, as is text. Recreating these realizations at new scale can be very expensive, so the XAML framework chooses to avoid creating any new realizations during animations. This reduces the chances of producing much more serious visual glitches during the animation.

When changing view states, then, a shape that’s been realized for a smaller scale will be used when scaling up to the larger view, resulting in blurriness, until the animation ends and the shape is realized at the final scale. It’s not a concern in the other direction, however, because a larger realization would get scaled down to a smaller, which works just fine except perhaps for other visual artifacts. (So the final realization after the animation will look better.)

The best workaround for this at present is to simply stop animations when an app gets resized, then start those animations again after the size change has finished. The XAML framework then has a static frame to use when resizing, which should produce better results.

Developers have sometimes asked what apps should do if edge gestures are accidentally invoked, especially for time-sensitive games.

Generally speaking, such apps should pay attention to when they lose focus, which can happen for left/right edge gestures as well as being snapped in favor of another app going into filled view and thus taking the focus. Many games, for instance, pause when snapped (also for playability's sake) and when the charms bar is invoked. The focus events that you can obtain on the top-level app window (e.g. the window object in JavaScript) help you out here.

For top/bottom swipes, these will invoke your own app bar if you provide one (otherwise they have no effect). In this case you can use the beforeShow/beforeHide (WinJS) or Opened/Closed (XAML) events to know when this happens.

More fundamentally, you can also use the events in Windows.UI.Input.EdgeGesture to detect the top/bottom swipes but this is a somewhat lower-level mechanism.

If you haven't seen it, the Designing great games for Windows topic in the docs is also worth a read on many other important points.


Along with testing the functionality of your app, it's also important to do performance testing on a variety of machines to make sure that your implementation is flexible enough to handle differences in processor speeds (for work on the UI thread) and GPU capabilities (especially affecting animations and rendering). Testing on different network speeds can also be helpful if you rely on online content–testing on a slow network, for example, can reveal the need to use progress controls in key places of your app (so the user doesn't think it's just hung). It can also help reveal places where you might implement strategies to avoid progress controls altogether, such as caching page content or switching between pages just with changes in visibility and not tearing down and rebuilding pages each time.

In any case, I wanted to provide some links to resources over a few posts. Here are a few topics in the docs for starters:

Performance (Windows Store Apps) – all languages

General Best Practices for Performance – all languages

Performance Best Practices – JavaScript

Performance Best Practices – C++, C#, VB, XAML

You'll also want to look at Tool: Performance Analyzer (JavaScript), which is one of the key tools to use for this task.

More to come later on–this is probably enough for you to chew on at present!


Though my primary focus is on Windows Store apps written in HTML, CSS, and JavaScript, I do see plenty of C#/XAML material cross my inbox. In this case, there’s a helpful template available in the Visual Studio Code Gallery that closes the gap between the HTML/CSS and XAML presentation layers, namely doing variable-sized items in a collection control, otherwise known as cell-spanning. This is built into the WinJS ListView control but takes a little more work in a XAML GridView.

The template found on helps close that gap. To quote the description: “VariableGridView is a subclass of GridView that supports variable sized children. When using the template, there should be no need to modify this class.”


A long time ago this question came up within my team at Microsoft, long before we did any public disclosure of the new system. Before Windows 8, there was really only one choice to write a native app without taking a dependency on an external framework or other middleware of some kind: C++ (or C) with UI layers like WinForms or DirectX. Windows 8, however, introduced other choices for native Windows Store apps, by which I mean one that has direct access to the system's API without relying on middleware to expose it (and thus require that middleware to be updated to take advantage of new system features). Those choices include using JavaScript with HTML/CSS as the presentation layer; using C#, Visual Basic, or C++ with XAML as the presentation layer; or going the C++ and DirectX route.

Early on, I remember people saying "Of course, JavaScript is the easiest language, so that would typically the natural choice." Well, JavaScript might be more forgiving in the beginning, and perhaps easier to get started with because of the lack of strong data types, but it soon becomes somewhat odd. For example, dealing with async APIs through promises involves a lot more code (and concern about closures) than using the await keyword in C#/VB. Furthermore, writing an app isn't just about the language, it's also about the presentation layer. Here, if you don't already know HTML and CSS reasonably well, you end up having two different specs with different syntaxes and different paradigms. Is that's necessarily easier? I commented a number of times that no one seems to have written book like  Crockford's JavaScript: The Good Parts for C# or XAML because the bad parts have already been expunged!

There are, of course, a few reasons why you might be forced to use one language/presentation choice over another. Protecting intellectual property is best done in C++, though not foolproof–and for that you can use a mixed-language approach to put more sensitive code into WinRT components written in C++. (It does also seem that better obfuscators for JavaScript are coming along…more on that another time.)

If raw graphics performance is a concern for your app, then going C++/DirectX ends up being your only real choice. Many kinds of apps can be effectively written in the other languages, but in the end, if perf totally matters to you, make the choice early to bypass any extra rendering layers you can (i.e. HTML/CSS and XAML). The team that created the FreshPaint app, for example, did this very early on as they had already implemented their paint/texture physics engine in C++/DirectX so there wasn't any reason to think to use a different language for the rest of the app's structures.

Similarly, if you really need to do multi-threaded work, you'll find that easier to manage all that in C++ and the APIs it has to offer. Trying to do the same with JavaScript workers probably won't give the results you want. C#/VB might work well too depending on your needs, but again, with a mixed-language approach you can put certain parts in components written in C#/VB or C++ and perhaps do outer app framework in HTML/CSS (assuming you don't need to share drawing surfaces, which can't be done from JS at present).

One potential advantage of HTML/CSS/JS is that you can write code that's more portable to other platforms where HTML-based options are available, including the web. This does require that you keep Windows-specific code isolate, in the way that tools like Phonegap/Cordova do, but it's possible. (Not that the Windows Library for JavaScript, WinJS, is already portable–it will use WinRT if it's available, otherwise it uses HTML5 APIs.) That said, options like Xamarin (for C#/XMAL) and Unity (for DirectX/C++) give you similar cross-platform approaches for the other languages.

There are a few cases where Windows 8 doesn't have exact parity between HTML/CSS and XAML, where HTML/CSS has a couple more controls. On the flip side, if you're trying to directly incorporate web content into an app, you have to use an HTML iframe if the content needs HTML5 capabilities like AppCache or LocalStorage, but then if the web site has frame-busting code, you have to use the x-ms-webview element which doesn't have all the HTML5 goodies, which also goes for the The XAML WebView. Clearly this is an area that can be improved, but for now, it's good to know that these limitations can make-or-break your language decision.

Clearly, if you have existing code in one language or another, then it makes sense to reuse much of that instead of porting it to another language. Once more, this is where a mixed-language approach comes into play.

All in all, the more we discussed this question amongst ourselves, the more we realized that there never really was a set answer for any given developer. We drafted a number of papers to try to spell out the strengths and weaknesses of each choice, but in the end, I whittled it down to these thoughts:

  1. If you already know one of the languages/presentation layers and not the others, and don't have a specific issue that would force you into a choice, then stick with what you know. Otherwise you'll have to face a big learning curve.
  2. If you know more than one of the languages/presentation layers already, then you don't need Microsoft to spell out the strengths and weaknesses: you understand those already and can make an intelligent choice.
  3. If you don't know any of them, then you should spend a couple hours working through the basic tutorials of the Windows Developer Center (the "Developing Apps" topics listed here), and see which one you like the best. I have generally figured that those coming from Java and Objective-C would probably pick up C# (or maybe C++) easier than learning the semi-mystical tones of CSS, whereas a web developer would typically find HTML/JS a familiar territory.

I was very glad, in fact, to see that the banners at //Build 2011 in Anaheim were emblazoned with the words "use what you know" where writing apps was concerned. An in working with partners building apps over the last year, that's pretty much played out to be the right way to approach the matter.