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):




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.