C++, C# and JavaScript on WinRT [closed]

Regarding #1, the line-up would be roughly as follows:

JavaScript - highest-level, dynamically typed, GC. You can only use HTML5/CSS for your UI, the XAML framework (Windows.UI.XAML namespace) is not available. Provides some standard JS APIs (specified by HTML5) in addition to the available surface of WinRT, such as local storage or IndexedDB. Being dynamically typed, heavy CPU-bound processing is likely to be slower than either .NET or C++, though the JS engine is still very fast due to being JIT-compiled and heavily optimized. You can consume C++ and .NET WinRT components, but not write your own in JS. Some aspects of language projection seem to be limited correspondingly - e.g. so far as I can see, there's no way to implement a WinRT interface in JS, for example. Existing JS libraries can usually be reused with no or minimal effort, so long as they work in IE10.

.NET (C#/VB) - mid-level, statically typed with optional dynamic typing (dynamic keyword etc) and GC. XAML UI framework is the default one for UI, but you can also use HTML by using WebView control. Provides full access to WinRT libraries, but also some of its own on top of that, which are sometimes more convenient to use (e.g. Stream vs IInputStream/IOutputStream). Also, the only one that includes special language-level support for asynchronous operations (async and await keywords), which are used heavily when using WinRT APIs due to their highly asynchronous design. Generally speaking, provides most syntactic sugar - aside from async stuff, you get LINQ to objects (which works over WinRT collections). Can write your own WinRT components, which can then be used from JS or C++/CX. Existing .NET libraries may or may not be readily reusable, depending on what classes in .NET Framework they rely on; components written for Silverlight or WP7 are most likely to be reusable with no or minimal changes, while components written for .NET 4 Full or Client Profile may require significant changes to run.

C++/CX (Visual C++ Component Extensions) - low/mid-level, statically typed, no GC - refcounting only. Closest "to the metal" in that its object model is designed to map directly to WinRT with no impedance mismatch - hence refcounting - but still high-level enough to avoid boilerplate and be generally safe to use (e.g. exceptions rather than HRESULTs, strings seen as objects and not handles, dynamic_cast rather than QueryInterface etc). No additional layers, proxy objects etc between you and WinRT, all calls are direct. In most cases, fastest of all three, though the exact difference varies significantly depending on the specific task, and can be minuscule for some (e.g. event-driven app with no or little computation), and considerable for others (e.g. parsing or heavy math). UI story is same as for .NET. In addition, you get the entire C++ standard library available to you, as well as a subset of ATL. Can write your own WinRT components, which can then be used from JS or .NET. Existing C++ libraries may or may not be readily reusable, depending on which APIs they use; those that relies strictly on Standard C/C++ will usually work with no changes, while those that call Win32 APIs may pose a problem if they rely on APIs not available in Metro app container.

Regarding #3, this video - http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C - should answer most of your questions regarding the use of Win32 (which I presume what "low-level DLL" means) from Metro apps. Note that while the video is about C++, this also fully applies to C#, as P/Invoke and COM Interop are still there. So if you can call it from C++, you can call it from C#.

1) The point of allowing language choice is to let you choose a language for the intrinsic advantages of the language and not because it is the only way to access an API. If you like dynamic languages, choose JavaScript. If you like static typing, but don't want to deal with memory, use C#. If you want the fastest execution (but the most ability to shoot yourself in the foot), choose C++.

2) That depends on what you mean by native. If you just mean that you want them to look like Metro style apps, the best way is to use the WinJS libraries that ship with the developer preview SDK.

3) WinRT gives you the ability to write and call your own C++ DLLs or C# Assemblies from your JavaScript code. The restriction is that you have to expose the DLL as a WinRT object and you can't call any functions that are not otherwise allowed to be used in Metro style apps.

1. Same differences as they have always had. There's no such thing as C# without automatic memory management. Managed languages will have similar overhead as always.

2. If it runs Javascript, you should be able to use jQuery (which is pure javascript). You may need to call some MS functions for initialization, etc., but existing script functions ought to still run.

3. The most reliable sources I've seen have indicated that (at least mostly) WinRT sits on top of Win32. That "Windows Kernel Services" block is Win32's kernel32.dll. Some upper-level Win32 stuff isn't used in Metro, but what application ever used ALL of Win32?