Why XAML? Why Now?
Tags: xaml, csharp, dotnet
Published: 2018-10-30 08:57:16

---
title: Why XAML? Why Now?
published: true
tags: xaml, csharp, dotnet 
canonical_url: https://www.telerik.com/blogs/why-xaml-why-now
---

XAML has stood the test of time and remains a flexible UI definition language. This article explores the app platforms that XAML powers today and looks ahead at what might be in store for future.

XAML is dead. No wait - Long live XAML. XAML (Extensible Application Markup Language) started life as a simple thin UI markup layer, but has had a surprisingly eventful history. Developers on Microsoft's technology stack have been witnesses to XAML’s phenomenal rise as well as its teetering on the edge of life support.

Turns out, XAML may be much loved or much hated, but has clearly stood the test of time. Over years, no one team at Microsoft owned XAML - it was meant to be a descriptive markup UI language to define visual trees for apps. So, several technologies adopted XAML and gave it character and unique dialects. Today, XAML stands strong powering various app platforms, sports rich tooling support and potentially has a very bright future. This article explores what XAML can power today with an eye out for what the future holds in store.

## Desktop

### Windows Presentation Foundation (WPF)

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/wpf.png)

The holy grail of Desktop development on Windows today is still [WPF](https://docs.microsoft.com/en-us/dotnet/framework/wpf/getting-started/introduction-to-wpf-in-vs) - which is where XAML started life. Over the years, XAML has always been the UI layer for WPF apps and has enjoyed rich tooling support. One might argue that much of XAML’s feature richness and ease of use stems from WPF. Both Microsoft and the developer community stepped up to make XAML/C# development a wonderful experience for developers. With code intellisense and design tools like Blend, the UI definition layer for WPF apps continues to be the gold standard for XAML development.

### Universal Windows Platform

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/uwp.png)

Starting from Windows 8 and after several iterations, Microsoft finally landed on [UWP](https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide) - the de facto way of building forward-looking apps for Windows. And sure enough, the UI layer is powered by XAML, albeit a slightly different dialect than WPF uses. XAML powering UWP apps is a big deal for developers comfortable with the markup language - primarily because of UWP’s reach. UWP can power apps on every modern Windows device, from tablets, laptops and desktops to XBoxes, Surface Hubs and the HoloLens. Developers get to define their UI in XAML and it simply works across all form factors.

While this sounds magical, the reality takes a bit of work to adjust layouts with a fluid UI for various device sizes - but it is all XAML under the covers. And UWP’s device flexibility means XAML sports rich features like responsive layouts, advanced touch support and inking capabilities.

## Mobile

### Xamarin.Forms

Being able to reach all Windows devices with XAML was nice, but no one lives in a platform silo. For mobile form factors, iOS/Android rule - .NET developers needed a bridge to carry their skills cross platform. Enter [Xamarin.Forms](https://docs.microsoft.com/en-us/xamarin/xamarin-forms/). With a shared abstracted UI layer, developers can share not only business logic but UI definition as well - all towards building truly native cross-platform apps. And the choice for abstracted UI definition? Yep, XAML - a special dialect of it catered for mobile app development.

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/XamarinForms.png)

Xamarin.Forms XAML did something wonderful - relieving .NET developers from having to learn the intricacies of native platform UI. Developers get to define the UI visual tree in XAML and the runtime turns around to render corresponding native UI components on each platform. Modern Xamarin.Forms development provides rich tooling for XAML development - like Forms Previewer, Inspector and Profiler.

### Uno

Is Xamarin.Forms XAML not quite your cup of tea? Turns out, a few smart folks from Montreal Canada are with you - and they love UWP XAML. Enter [Uno](https://platform.uno/) - now an open source UI abstraction library that creates bridges to iOS and Android from XAML. Uno’s application runtime is powered by Mono and Xamarin - developers simply get to use UWP XAML, instead of the Xamarin.Forms head. This was no small effort since the corresponding native UI is being rendered on each platform. It's all worth it just for the love of UWP XAML.

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/Uno.png)

### NativeScript

A lot of enterprises that have traditionally had a full .NET technology stack, now power their web app frontends with SPA frameworks - like Angular, React or Vue. Most modern .NET developers aren’t shy about writing JavaScript, CSS and HTML. And if web technologies are what’s powering your apps, then JavaScript Native apps are rather enticing as a mobile strategy. Developers get to reuse web technologies to power truly native cross-platform mobile apps - and potentially share code between web and mobile.

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/NativeScriptLogos.png)

[NativeScript](https://www.nativescript.org/) is an open source framework for building JS Native mobile apps. Developers get to write straight up JavaScript or TypeScript with Angular for the app’s business logic. And the abstracted UI layer is defined in XML - a JS bridge renders corresponding native UI at runtime. While officially XML, let’s take a look at standard UI definitions in NativeScript - look familiar? Yup, that’s almost XAML, and .NET developers with any XAML experience will be perfectly at home here.

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/NativeScriptXAML.png)

## Web
 ![Microsoft Silverlight](https://d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-10/silverlight4d42cf5f8c874f399149351fa66033ea.png?sfvrsn=e54d6eeb_1&MaxWidth=325&MaxHeight=&ScaleUp=false&Quality=High&Method=ResizeFitToAreaArguments&Signature=67DEA073D9D95EB41758042C13977BFA39067953 "Microsoft Silverlight")

XAML powering apps on the web browser has had a checkered past. Understandably, .NET developers who did Silverlight are still hurt - it is never a good situation when technologies die and take down investments. The web has simply moved away from the Plugins model and Silverlight saw the writing on the wall. Folks who did Silverlight development though were actually quite fond of the developer experience - XAML/C# was beautiful in the browser and the rich tooling helped. There may be some longingness to see XAML back on the web - but done with better architecture.

### WebAssembly
 ![WebAssembly](https://d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-10/wasmlogo4832c37fb3854896b199c5142701fd3f.png?sfvrsn=e39b4771_1&MaxWidth=325&MaxHeight=&ScaleUp=false&Quality=High&Method=ResizeFitToAreaArguments&Signature=E538A8E281332CDBDFA32FAB53D1453591C9CDB5 "WebAssembly")

Enter [WebAssembly](https://webassembly.org/) - a low level instruction format that modern evergreen browsers can execute natively, just like JavaScript engines execute JS code. Being an open web standard, WebAssembly is enjoying support from big browser vendors, with promises of security and native execution speeds. The biggest draw of WebAssembly is the promise of compiling code written in higher level languages into stack-based instructions that browsers run natively - this [opens a lot of doors](https://dev.to/progresstelerik/goodbye-javascript-hello-webassembly-6oc-temp-slug-9525238).

### Mono
 ![mono](https://d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-10/monoc1dba5be8f3d4f75af22c6fb8938b335.png?sfvrsn=cb8284f9_1&MaxWidth=325&MaxHeight=&ScaleUp=false&Quality=High&Method=ResizeFitToAreaArguments&Signature=89229B53C7C19266E14E6D88B94E2A3D7969094D "mono")

[Mono](https://www.mono-project.com/) has been around since the early days of the .NET Framework, as a popular port of .NET APIs to platforms outside of Windows. Over the years, Mono has matured to provide a large API surface area and .NET API mappings on other platforms like Mac/Linux, thus enabling .NET apps to step outside of Windows. Mono continues to power all of Xamarin - it is clearly the easiest way to take .NET code and run it on iOS/Android.

Turns out, folks at Mono are plenty smart and work is underway to bring [Mono to the WebAssembly platform](https://www.mono-project.com/news/2017/08/09/hello-webassembly/). This has the wonderful potential of compiling C# code down to WebAssembly that the browsers can execute natively, Hallelujah! This is exactly what’s powering [Blazor](https://blazor.net/index.html) - the experimental ASP.NET web framework promising to bring C# to the browser with Razor syntax. While the [present Mono support for WebAssembly](https://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/) may be through Mono IL interpreter to run managed code at runtime, support for full static Ahead Of Time (AOT) compilation isn’t far away. This should lead to excellent performance of C# code on the browser.

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/MonoWASM.png)

With C# coming to browser natively, it didn’t take long for XAML afficianados to demand the UI abstraction layer back - this time, done through WebAssembly instead of using a Plugin. While experimental, it turns out both Xamarin.Forms and UWP XAML can already power web apps in the browser through WebAssembly.

Meet [Ooui](https://github.com/praeclarum/Ooui) - a small cross-platform UI library that brings the simplicity of native UI development [to the web](https://www.telerik.com/blogs/xamarin-forms-on-the-web). Ooui.Forms provides Xamarin.Forms renderers for the web with a shadow DOM powering the front-end app - it can be hosted by itself or as a part of ASP.NET Core. There are several [online samples](http://ooui.mecha.parts/) to play around with and see the fun of having XAML back in the browser. Also, Ooui.Wasm allows for packaging Xamarin.Forms apps with XAML UI markup into a WebAssembly runtime. It is nice to see a Xamarin.Forms apps, compiled statically and hosted on Amazon S3, [running purely as WebAssembly on the browser](https://s3.amazonaws.com/praeclarum.org/wasm/index.html).

Not to be left behind, UWP XAML also finds its way back in the browser - thanks to Uno. The experimental WebAssembly support looks polished, especially when trying things out in [Uno’s WebAssembly Playground](https://playground.platform.uno/). Write, edit and see XAML running in browser natively - how magical.

## Looking Ahead

### MVVM Frameworks

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/MVVM.png)

A big part of why .NET developers are fond of XAML development is the rich tooling and ease of maintaining large codebases. Model-View-ViewModel (MVVM) is a design pattern that works really well for XAML/C# development and there is plenty of help on this front. There are rich MVVM frameworks that have evolved over the years to support WPF/UWP platform development and now they have been customized to work for Xamarin.Forms as well. The open source .NET developer community really shines through with these MVVM frameworks - a lot of effort has gone into building feature richness and Visual Studio templates for each of the frameworks. Popular ones are [MVVM Light](http://www.mvvmlight.net/), [Prism](https://github.com/PrismLibrary/Prism) and [MVVM Cross](https://www.mvvmcross.com/).

### Xamarin.Forms Heads

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/XFHeads.png)

An interesting set of developments for XAML developers is the increasing number of heads/backends for Xamarin.Forms - this simply increases the number of platforms supported and takes your code places. Xamarin.Forms is open source and the developer community is smart. The result is new Xamarin.Forms heads like MacOS, GTK Linux, WPF, Tizen and even the web - Xamarin.Forms apps are now starting to power so many platforms outside of just mobile. And the abstracted UI layer is your beloved XAML.

### Marzipan

Apple has been having an app gap problem - most developers build for iOS, but not much for the Mac AppStore. Their remedy is an internal project codenamed ‘[Marzipan](https://www.strv.com/blog/unlocking-marzipan-uikit-on-macos)’ - aimed for fruition some time in 2019. The goal is get iOS apps running on the Mac desktop through a mashup of UIKit and AppleKit - and there are several demos Apple has shown off already. Now this obviously has to be done carefully - there are implications when we take touch apps back to the desktop with mouse/keyboard.

So why should .NET/XAML developers care about Marzipan? Turns out, we’re talking iOS apps running on Mac desktop with minimal changes. And the iOS apps can be written in Xamarin.Forms or Uno - this means XAML can officially power desktop apps on the Mac. Given XAML’s richness to handle responsive layouts, one can argue that XAML developers should be able to port their iOS apps fairly easily to the Mac.

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/Marzipan.png)

### Polished UI

Another reason for loving XAML/C# development is the rich ecosystem. Most professional apps need complex performant UI and developers need not reinvent the wheel - there is a lot of help. Enter [Progress Telerik](https://www.telerik.com/) - your beloved .NET tooling across web, desktop and mobile.

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/Telerik.png)

Telerik offers multiple UI suites catering to different platforms for XAML developers. What’s common are feature-rich UI controls, full MVVM support, consistent APIs and professional themes for styling. The engineering efforts behind each UI component shows in performance and pixel-perfect rendering - developers love complex UI that they can just drop in to light up apps. Popular controls include Grids, ListViews, various Charts/Graphs, Calendars, SideDrawers and myriads of other UI that is difficult to create by hand.

While [Telerik UI for WPF](https://www.telerik.com/products/wpf/overview.aspx) provides powerful UI for desktop apps, [Telerik UI for Xamarin](https://www.telerik.com/xamarin-ui) powers mobile apps across all platforms - and yes, all with XAML as the UI stack.

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/TelerikXamarin.png)

While the modern web may have moved away from Plugins model, many enterprise Silverlight apps still power line of business workflows. To that end, [Telerik UI for Silverlight](https://www.telerik.com/products/silverlight/overview.aspx) is there to help and sees continued feature investments. Building for Windows devices? [Telerik UI for UWP](https://www.telerik.com/universal-windows-platform-ui) is there to help with polished performant UI - and entirely free and open source.

![](https://www.telerik.com/sfimages/default-source/blogs/2018/2018-10/TelerikUWP.png)

### XAML Standard

As discussed, we have a few flavors of XAML now - WPF, UWP and Xamarin.Forms each talk slightly different dialects. This leads to a bit of fragmentation and some frustration for developers, mostly over annoying little differences and varying XAML namespaces. Wouldn’t it be nice if all platforms spoke the same XAML?

That’s exactly what [XAML Standard](https://developer.telerik.com/content-types/tutorials/xaml-standard-demystified/) aims to do - unify all XAML dialects into a common language across WPF, UWP and Xamarin.Forms. The specifications for XAML Standard are being chalked up [out in the open](https://github.com/Microsoft/xaml-standard) with developer community feedback and initial efforts aim to create aliases to smooth out XAML differences across platforms. However, XAML Standard has taken on a particularly difficult problem - the XAML across various platforms is often too focused on platform specifics. The road ahead is rough for XAML Standard, to say the least.

## Unified UI Stack

So clearly, XAML as the UI layer is much loved and has stood the test of time. XAML today powers several app platforms across desktop and mobile, and the experimental efforts are underway to bring XAML back to the web browser. Developers enjoy rich tooling for XAML development and a thriving community provides support.

However, one can also argue that there are mixed messages around XAML. There are multiple ways of building the XAML UI stack for mobile/desktop and true cross-platform solutions require a lot of work. Could there be a silver lining in the horizon?

Turns out, .NET Core updates have come in waves. .NET Core 1.x was all about taking the CLR cross-platform - so .NET apps could step outside of Windows. .NET Core 2.x stabilized the ship - most missing APIs were reinstated and web development tooling came of age. .NET Core 3 would be all about taking the benefits of .NET Core back to the desktop for WPF/WinForms apps. Could the .NET Core 4.0 wave see the cross-platform UI story be addressed?

Wouldn’t it be nice if there was a uniform UI layer that was consistent and worked cross-platform for web/desktop/mobile? We can conjecture about the future, but XAML is likely the most obvious candidate to pull off the heist. Fingers crossed and cheers to the future!