MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

Choosing a Mixed Language Approach (and Web Workers)
There are many reasons to take a mixed language approach in your app, which can again include any
number of WinRT components written in C#, Visual Basic (hereinafter just VB), and/or C++:
• You can accomplish certain tasks faster with higher performance code. This can reduce memory
overhead and also consume less CPU cycles and power, an important consideration for
background tasks for which a CPU quota is enforced—you might get much more done in 2 CPU
seconds in C++ than with JavaScript, because there’s no language engine involved.
• C#, Visual Basic, and C++ have access to a sizable collection of additional APIs that are not
available to JavaScript. These include .NET, Win32, and COM (Component Object Model) APIs,
including the non-UI features of DirectX such as XAudio and Xinput. We’ll see a number of
examples in the “Access to Additional APIs” section later in this chapter.
• Access to other APIs might also be necessary for utilizing third-party .NET/Win32/COM libraries
and also gives you the ability to reuse existing code that you might have in C#, VB, or C++. The
Developing Bing Maps Trip Optimizer, a Windows Store app in JavaScript and C++ topic shows a
complete scenario along these lines, specifically that of migrating an ActiveX control to a WinRT
component so that it can be used from an app, because ActiveX isn’t directly supported. (We
won’t cover this scenario further in this chapter.)
• It can be easier to work with routines involving many async operations by using the await
keyword in C# and Visual Basic, because the structure is much cleaner than with promises. An
example of this can be found in the Here My Am! app of Chapter 17, “Apps for Everyone,” where
the transcodeImage function written in JavaScript for Chapter 13 is rewritten in C# (see
Utilities.ImageConverter.TranscodeImageAsync in the Utilities project).
• A WinRT component written in C++ is more effective at obfuscating sensitive code than
JavaScript and .NET languages. Although it won’t obfuscate the interface to that component, its
internal workings are more painstaking to reverse-engineer.
• A WinRT component is the best way to write a non-UI library that other developers can use in
their chosen language or that you can just use in a variety of your own projects, like the
Notifications Extensions library we saw in earlier chapters. In this context, see How to: Create a
software development kit, which includes details how the component should be structured to
integrate with Visual Studio.
• Although you can use web workers in JavaScript to execute code on different threads, a WinRT
component can be much more efficient for custom asynchronous APIs. Other languages can also
make certain tasks more productive, such as using language-integrated queries (LINQ) from
C#/VB, creating parallel loops in C#/C++, using C++ Accelerated Massive Parallelism (AMP) to
take advantage of the GPU, and so on.
718