No comprehensive survey about UIs can ever be complete without covering the Microsoft world. Java and JavaScript may be all good and well, but sometimes you need more control over your hardware. Both languages run in a sandbox trying to abstract from the hardware the application is running on. Most of the time you won't notice, but there's a major performance penalty, and you can't access low-level resources. So let's have a look at what Microsoft has in store for you. Traditionally, the particular advantage of using native Windows programming is the seamless integration with the operating system and - to a lesser extent - with the hardware.
So let's have a look at Microsoft's UWP platform and at Xamarin, a framework they've acquired in February 2016.
Kudos to my co-author
But before that, I'd like to introduce you to my co-author, Janis Saritzoglou. This article wouldn't have been possible without him. Janis wrote his bachelor thesis about UWP and dedicated an afternoon to explain UWP and Xamarin to me. He also proofread this article and added a couple of interesting insights.
That said, let's continue with UWP.
Targeting multiple devices
Oh, our introduction led you into the wrong direction. One of the key concepts of UWP and Xamarin is platform independence. It goes without saying that the tradeoff is less control over the hardware. If you need full control over your hardware, you have to use older UI frameworks like the WPF (Windows Presentation Foundation) framework. However, the designers of the UWP framework found an interesting compromise. Two interesting compromises, in fact.
The first is "adaptive programming". When writing a UWP app, you first decide which platforms you want to target. The list ranges from Windows-based desktop PCs over Windows tablets and smartphones over IoT gadgets like Raspberry Pi to a gadget that's completely different: the hololens. Xamarin also adds iOS and Android to the equation. Even MacOS development is supported.
The initial selection amounts to reducing the set of OS features you can use. Both the IDE and your application know the limitations of your target platform, so the IDE only offers only classes and methods that are available on every target platform. So the lowest common denominator of .NET classes can be used based on your selected platforms. Later, when you're publishing your application at the Microsoft store, the application is only offered to compatible devices.
But there is one thing more to decide before starting the actual developing. Xamarin/UWP wants you to select one of two different ways how your code will be shared across platforms. The options are Portable Class Libraries (PCL) projects and Shared Asset projects (SAP). The main difference between them is the way you implement platform specific behavior. If your choice was SAP, you use compiler directives to realize platform specific behavior. Especially when it comes to a large project, this will cause a lack of code readability, because it may hard to decide which code will run on which platform at runtime. PCL projects, on the other hand, are more often used and allow to implement platform specific behavior easier. The cost of it's easier usage is you can only use a subset of .NET classes. As mentioned before, the subset of available .NET classes depends on the combination of platforms you've selected.
Adaptive programming
Now for the adaptive programming part. After defining the list of target platforms, you can add platform you want to support optionally. From a programmer's perspective, that's adding libraries. Of course, you can't use such a library without guards. Before accessing a platform-specific API, you have to ask the framework whether the current device supports this API. Needless to say, this may result in a lot of if statements. A small comfort is is that you can specify some static platform specific things declaratively in XAML. On the plus side, you can access specific capabilities of certain devices and still be able to target a whole family of different target platforms. Just think of the IoT target platform, which may include your fridge. It's not a big surprise you can't run a computer game running on a Windows 10 within your refrigerator, but it's pretty cool that adaptive programming allows you to take advantage of both the specific capabilities of both your fridge (possibly the thermometer? Or a device tracking what's stored in the fridge?) and the desktop PC (the powerful graphics card allowing you to display 3D graphics in real time).
Responsive design
Talking of which, the current version of UWP also includes responsive design. Note that the Microsoft documentation calls it "adaptive design". Plus, responsive design is an option you have to activate manually.
Architecture and design paradigms
By now you might have noticed that the article is a tad different from the articles covering Java and JavaScript frameworks. That's one of the surprises I encountered when I investigated this article. The Microsoft developer community seems to be far less obsessed by design patterns and architecture than the Java community. I wrote my first Windows program with Visual Basic 2.0, and I felt immediately at home when I watched my co-worker Janis showing me the programming model of UWP. I suppose this means this is pretty low-level stuff. UWP and Xamarin concentrate on providing great components and tools, but they don't spend too much time on telling you which design pattern you have to use. In fact, a quick Google search didn't tell me whether MVC, MVP or MVVM is the appropriate programming model for UWP applications. Each of these paradigms is known in the Microsoft world, but judging from the Google results, none of them is a clear favorite. In fact, I even got the impression hardly anybody really cares.
Probably more important is the "code behind" approach of Microsoft. They separate the code into at least two parts: the view and the code-behind class, which strongly resembles the controller in the MVC model. Both bear the same name. The difference is the file name extension. Usually, the view is a *.xaml file. In other words, it's an XML file describing the view, much like the *.xhtml file in JSF or the *.fxml file in JavaFX. However, UWP also offers the option to define the UI programmatically. This approach resembles Swing in the Java universe. The difference is that UWP allows you to combine both approaches. Every once in a while, this comes in handy.
Other than that - well, it seems to be up to you which (if any) paradigm you want to follow. Judging from my experience, you should follow the MVP pattern, but the UWP community seems to be more pragmatic. Everything that works is allowed.
Target languages
Basically, UWP supports every language running on the CLR. Among others, this includes C# and VB.NET. I've also read about JavaScript support, but if I'm not mistaken, this only covers certain use cases. You can't write a major UWP application using JavaScript exclusively.
Note that C# and VB.NET also are used if your target platform is Android or iOS. Xamarin cross-compiles the code. At first sight, this sounds pretty cool, and it is. But soon you'll notice the drawbacks: first, you have to deploy the application remotely. Second, can't use the full power of your target platform. Remember the "least common denominator" bit. Plus, you may be able to compile an application both for Windows and iOs from the same source code, but the resulting binaries are different. Even worse, in this particular scenario, you need two computers just to be able to assemle the binaries. Mind you: a Windows PC can't package an iOS app, and a Mac can't build an Windows 10 app.
Components and component libraries
Visual components are the building blocks of an UWP application's UI. These components have a more limited scope than they have in JSF, not to mention Angular2, which builds the entire application around components. By default, the component palette of UWP consists of what you'd expect: input fields, buttons, things like that. Several components indicate the strong focus on mobile devices. Just think of cards, a popular building block of UWP applications.
There are also commercial component libraries, but currently, they are sparse. Probably that's because UWP is a very new framework. It takes some time to develop commercial component libraries (or open source libraries, for what it's worth).
Cutting a long story short: there are component libraries for UWP, and it's also possible to develop a custom component, but most people seem to be happy with the predefined set of UI widgets. Also, custom components often break the native design of the specific os.
Dependency management with NuGet
Recently, the dependency management system of UWP has been improved. Now it supports transitive dependencies and takes care about classes requiring different versions of the same library. Sadly sometimes there are problems with the Android dependencies because NuGet allows you to update the Android packages that are so new, that Xamarin gets incompatible with them. So you have to downgrade. Chances are this is going to improve over time, but you should be aware of this kind of problems.
Going native
Do you care about performance? If so, UWP has good news for you. Apart from the one-size-fits-all approach that's compatible with every target platform, you can also use native APIs for your target platform. According to Microsoft, this results in a 40% to 60% performance boost. The drawback is that you loose a lot of portability, and you have to write different code for different target platforms.
Development in Visual Studio 2015
After a few weeks with UWP development in Visual Studio 2015 combined with the Xamarin extension, we observed a couple of more and less disturbing problems. The most annoying thing was that you have to make changes in your XAML-Pages, save them and close the file (virtually about a trillion times. Otherwise, the code-behind file doesn't recognize the ids of the XAML-Page components. This problem mostly occurs after a restart of the IDE. Furthermore, there were problems with the NuGet package compatibility every once in a while.
Look and feel
UWP is designed to blend in smoothly with Windows 10. That's a very reduced design language.
Things slightly change when you install the same application on an Android or iOS device (using Xamarin). Both platforms use their own design language. Again, UWP applications blend in almost seamlessly. Given the differences between the platforms, that's no small feat. But of course, there are limitations. For instance, there's a calendar widget for Windows 10 applications. But there's no such thing on iOS or Android. Come to think of it, there's no native application using a calendar widget, apart from the calendar application itself. You can use a date and time picker, but that's a different component.
By the way, most of the time you don't notice, but since a couple of years, both platforms also sport a minimalistic design. Gone are the times of fancy 3D icons throwing shadows. On second sight, you'll observe a couple of minor differences. For example, there is a frame around choice lists on iOS. Hopefully, the next updates will fix that.
Wrapping it up
The fascinating thing about UWP is the wide range to devices you can install an UWP app on. It runs on such different devices like iOS, Windows 10 desktop PCs and the Hololens.
It's hard to tell whether I recommend UWP or not. I'd say it depends both on your use case and on the skill of your team. If they are familiar with Microsoft languages like C# or VB.NET, UWP is clearly a go. If they are more familiar with Java or JavaScript, there's little reason to choose UWP. Unless you want to support target platforms that don't support browsers or Java yet.
Dig deeper
Cheat sheet for Windows 10 UWP developers (in German language)