Modern Apps - Understanding Your Language Choices for Developing Modern Apps

By Rachel Appel | September 2013

Rachel Appel Developing modern software using a single language just doesn’t happen in 2013. Programming has evolved to a polyglot model with domain-specific languages (DSLs) for each tier of development. For example, a popular scenario is to use SQL and C# on the back end and HTML, JavaScript and CSS as the UI languages. As a developer, you want to be able to add skills to your skill set, but working in too many languages spreads your skills thin in each. You also want to put products out to market quickly, which often leaves little room for learning a new language and all its quirks, so optimally you want to build on top of skills you already have. When creating Windows Store and Windows Phone apps, you have a variety of choices in languages for every project scenario, and at least one will nicely complement your experience. In this article, I’ll show you what languages go with different development scenarios. In addition, I’ll look at the options you need to weigh and how factors such as data access or porting an app affect the language you need to use.

The Landscape of Modern App Languages

Here are the available language sets for Windows Store app development:

HTML, JavaScript and CSS
XAML and C#, or XAML and Visual Basic .NET
XAML and C++, or DirectX and C++

If you develop on the Microsoft stack, at least some of these languages should be familiar and, of course, Web developers know HTML and friends quite well. It makes sense that many of the same language sets are available for Windows Phone development: XAML with C#, Visual Basic .NET, and C++.

What about HTML, JavaScript and CSS for Windows Phone? At the time of this writing, the only way you can write HTML in a Windows Phone app is by using a WebView control, a technique normally seen in hybrid apps (these are half-Web, half-native app mutants).

If you’re creating a cross-platform native app (not a Web site) outside of the Microsoft ecosystem, the language landscape changes to these two options:

Java for Android
Objective-C for iOS (technically there are more options, but I’ll discuss only Objective-C here)

Fortunately, Xamarin has come to the rescue for .NET and Windows developers who want to write cross-platform apps. There’s no need to learn Java (although it’s quite similar to C#) or Objective-C, the language of iOS development (more on this later).

Now that you have a solid idea of what languages are available to use, I’ll look at how easy or difficult each one is to learn.

The Language Learning Curve

The path of least resistance is often the best path to take, and it’s certainly the fastest. The languages you and your team are familiar with are an important consideration when moving into new territory. Not everyone seamlessly transitions from one language to another, particularly with languages that behave completely different. It’s more difficult for some junior developers because they usually lack experience with different language paradigms and therefore more frequently make mistakes or are unaware of common pitfalls. Even seasoned developers who move from a compiled language such as C# to interpreted JavaScript can experience a lot of pain because they don’t realize tiny quirks of the language such as the this keyword behaving differently, that hoisting occurs, or the myriad other JavaScript oddities.

Fortunately, Web developers continue to enjoy working with the same HTML, CSS and JavaScript as they would in any client Web project, but the difference when writing for Windows 8 is the addition of the Windows Library for JavaScript (WinJS). WinJS makes it easy to write native apps on Windows 8 with Web languages. You continue to use the same open standard APIs as in Web development, but you also work with Windows-specific libraries to access the native experience.

Developers who are accustomed to Web languages will find that the trick to HTML controls in Windows Store apps is that they’re simply elements marked with data-win* attributes. Using these attributes allows the core WinJS code and some CSS to transform those elements into beautiful UI widgets that make a rich native experience. The WinJS code that renders the controls contains CSS rules that apply the look and feel of the Windows 8 modern UI. The core WinJS code also creates the more complex controls such as date pickers and grids at run time, and can add data-binding HTML elements to JavaScript arrays or objects.

XAML developers from both the Windows Presentation Foundation (WPF) and Silverlight camps continue to write the same declarative XAML for the UI layout alongside C#, Visual Basic .NET or C++ as its compiled companion. As you might expect, in XAML there are new libraries and namespaces dedicated to the Windows 8 modern experience.

There’s a great amount of parity among the declarative languages—that is, any “ML” language—concerning the amount and quality of UI controls. In general, if you find a control in XAML, it likely exists in HTML or the WinJS library and vice versa; however, there are one or two differences between the two.

XAML developers will hardly notice a change except for some namespaces and other trivial changes. Expression Blend is still a great tool to do UI design in XAML, while Visual Studio is best for the compiled language behind the scenes. A widespread third-party ecosystem exists around XAML UI controls, such as grids for XAML on the WPF platform, and many of these controls work the same way or similarly between Windows Store and Windows Phone apps.

Finally, if you’re a Windows Forms developer, it’s time to learn XAML, as you practically have no other choice. There’s no comparable UI language that you can use, because Windows Forms doesn’t have one—it’s all C# or Visual Basic .NET behind a design palette. While you can carry your general .NET and language skills over, you must learn the DSL of the UI: XAML. You could learn HTML, but that would require the addition of both CSS and JavaScript, so you’d then have three languages to learn, and that’s no small undertaking.

Data Access Affects Language Choice

How you access data varies—sometimes greatly—between languages, and the kind of data you’re dealing with determines how you access that data, as well. To start, some techniques are available only to one set of technologies or another, as is the case with Web Storage (also known as DOM Storage, which you can learn more about in my blog post, “Managing Data in Web Applications with HTML5 Web Storage,” at bit.ly/lml0Ul) and IndexedDB, both of which you may only use with browser-based languages such as JavaScript.

Windows Azure Mobile services (which you can learn more about in another blog post, “Use Windows Azure Mobile Services to Power Windows Store and Windows Phone Apps,” at bit.ly/15nhO8d) and the Windows Azure platform offer several native APIs for all the popular platforms as well as REST APIs that are inherently cross-platform. Because REST is an open standard, you can access its data from any language, anywhere, at any time, via a consistent interface. REST interfaces make it easy to develop across platforms because—despite language syntax and quirks—the code has a general consistency, or pattern. Public APIs, such as those provided by Twitter, Facebook, weather services and so on, usually return JSON or XML (or both) that you can consume via REST or XMLHttpRequest (XHR).

SQLite is a local database option available across all platforms and languages. SQLite is available as a NuGet package for Windows Store and Windows Phone apps in Visual Studio 2012. You can also access it through a Xamarin toolset and use its libraries to access SQLite databases on iOS and Android. SQLite is easier to use with XAML apps than HTML apps.

File access and file I/O on the Windows platform are at par level between Windows Store XAML and HTML apps, so the language doesn’t really matter when your app requires reading and writing to the file system. Although normal HTML and JavaScript in the browser have many restrictions on file I/O operations and accessing system resources, the Windows Store app development model allows more than sufficient access to the file system while maintaining security.

For complete details on data-access technologies for Windows Store and Windows Phone apps, see my March 2013 column, “Data Access and Storage Options in Windows Store Apps,” at msdn.microsoft.com/magazine/jj991982.

Cross-Platform Considerations

Objective-C is syntactically and operationally different from the other languages, as Java and C# behave similarly because they’re managed languages. However, if you’re writing cross-platform apps, you aren’t doomed to separate codebases such as Objective-C for iOS, Java for Android and C# for Windows platforms, because the aforementioned Xamarin tools make it easy to write in C# and generate Java and Objective-C. Xamarin provides a native code-generation toolset for cross-platform device development (that is, mobile and tablet devices), and it’s the lowest common denominator for doing cross-platform native development. As a result, developers from just about any platform can easily move their skills to the Windows platform or cross-platform via Xamarin and C#. Developers from the iOS and Android platforms would do well to pick C# as their language of choice if they want to publish on the Windows platform as well as the others. Note, however, that some developers in Redmond disagree, advocating that it’s more convenient to develop libraries in C++ and C because they can be accessed by iOS (directly) and Windows apps (via Windows Runtime, or WinRT, components). They point out that this approach is “free” (most Xamarin tools cost money) and more performant than third-party tools. I favor just creating and sharing Xamarin components, as time to market is more important than the negligible performance benefits—and I don’t particularly like using C++.

Porting from Legacy Codebases Affects Language Choice

Not all apps are greenfield apps (that is, new or rewritten). Most, in fact, are brownfield—or legacy programs—especially if the code you’re writing is for the enterprise. Many apps are really parts of a larger ecosystem of software made of multiple apps or multiple UIs that interact with business logic, service layers, public APIs or libraries.

Migrating Web apps in particular can be tricky, as you often need to keep the content of an existing Web site intact yet integrate that same content into the client app and make it feel like a native experience. This is because business requirements frequently dictate that the original Web site or architecture must remain unchanged. This can cause the look and feel of the app to be different from its host OS, making usability difficult, and it can block the user’s natural workflow. Fortunately, if you’re porting an existing Web site or app, you often have the choice to integrate instead. If this is the case, then the Apache Cordova framework (formerly PhoneGap) can help. Cordova enables you to create hybrid, Web-native apps by integrating Web content and native UI components and publishing across platforms. Conversely, integrating Web content with a native WinJS Windows Store app isn’t difficult to do using WinJS, and the experience is usually smoother for the user. Native apps enjoy a closer integration experience with the OS than client Web apps do, because native apps have access to modern hardware resources such as the camera, microphone, device settings, accelerometers, geolocation and so on. In addition to this, native apps have a distinct lifecycle and contain state, whereas Web apps are lightweight and stateless.

The Purpose of the App Matters

The type and purpose of your app determine the language you use, to an extent. High-intensity games and graphics apps lend themselves to languages such as C++ and DirectX (now part of the Windows SDK) because you can get closer to the machine and gain performance and better device control. DirectX is a complete collection of close-to-the-metal APIs you can access via C++ to create stunning games and apps. The downside of C++/DirectX is complex code that makes it easy to get yourself into trouble. C++ isn’t the only option for games, either. JavaScript—yes, JavaScript—apps are top performers, especially for canvas games. The Windows Store app execution container offloads script processing to the GPU so JavaScript can run in parallel yet independent of the layout done by the Trident layout engine. This notion of offloading makes JavaScript a really fast language that can perform just as well as native code. If performance is a big deal for you but you don’t want to learn C++, using the HTML canvas means you might not have to.

If you write business and productivity apps, you usually have your choice of any language that suits you, because things such as performance and UI controls are so similar. These apps tend to be common forms-over-data apps. The current set of technologies is what normally drives language and technology choices for these kinds of apps.

What About F#?

Wondering what happened to F#? While F# isn’t one of the basic templates for Windows Store and Windows Phone app development, you can reference and consume components created in F#. It’s also a great language for processing analytics and running code on the back end—and all apps need a back end.

Web developers often use a mix of CSS for styling HTML and JavaScript that together build modern UIs. Native developers also have a set of concurrent languages for the same, so it’s up to you to consider all the factors that might affect your app when choosing a language.

Rachel Appel is a consultant, author, mentor and former Microsoft employee with more than 20 years of experience in the IT industry. She speaks at top industry conferences such as Visual Studio Live!, DevConnections, MIX and more. Her expertise lies within developing solutions that align business and technology focusing on the Microsoft dev stack and open Web. For more about Appel, visit her Web site at rachelappel.com.

Thanks to the following Microsoft technical experts for reviewing this article: Eric Schmidt (erschmid@microsoft.com) and John Kennedy (jken@microsoft.com)