What is the future of XAML?

Is XAML a dying language? It's a pretty common question with a not-so-simple answer. Still, we can get a solid idea of where it's all heading by taking a look at the language from its conception to its current state. By the time we're finished, you should be able to answer this one incessant question: Is XAML still worth your time?

The beginning

XAML is a declarative markup language typically used to create an application's user interface. It got its start in 2006 when Windows Presentation Foundation (WPF) was introduced as part of the .NET Framework 3.0.

Positioned as the follow-up to Windows Forms, it's no wonder adoption was slow. The typical applications you'd build with this were line-of-business versions, living inside corporate walls. As you've probably experienced, the standard attitude in these environments is to wait and see how a new technology will fare, rather than just jumping right in. Next to that, the learning curve was pretty steep, which would have resulted in higher costs. And, to be frank, WPF was plagued with performance problems.

Steadily, it got better, and when Silverlight came around things started looking brighter for XAML. Silverlight was introduced as a cross-browser, cross-platform plugin in which you'd use XAML to build your UI. This was also the time when Microsoft introduced its “one technology, three screens” vision – and XAML was an unmistakable part of this.

Silverlight

Back then, I was a heavy proponent of Silverlight, but time proved me wrong. In April 2010, Apple co-founder Steve Jobs wrote an open letter stating that the tech giant would no longer allow Adobe Flash on iOS. Due to the fact that mobile was – and still is – gaining importance, this essentially resulted in the death of Flash. And with the death of Flash, it was written in the stars that the browser plugin, in general, was running on its last legs – including Silverlight.

Some folks considered the death of Silverlight a prelude to the death of XAML. Bright, clear blue skies turned into thunderstorms, and developers who had invested their time and money in learning XAML felt like they were being left out in the cold.

Microsoft released Windows Phone, allowing developers for that platform to use Silverlight for Windows Phone. Development on WPF seemed stagnant for a while, but new investments in its active development were made. This could be seen as a sign that Microsoft would keep on investing in XAML, but the developer community was still worried.

Shift in focus

And then, Windows 8 was announced with the Windows Runtime (WinRT) architecture, an unmanaged application programming interface. WinRT allows interacting from multiple languages: C++, C#/VB.NET, and JavaScript. To build your UI, you could use XAML (typically in combination with C#), but what attracted the most attention was the ability to now build applications for Windows 8, targeting WinRT using CSS and JavaScript.  This is what Microsoft focused heavily on when it launched this new platform.

(Sidenote: The advent of WinRT essentially means the decline of .NET on the client; Windows Store applications can be built without using the CLR at all.)

XAML developers felt like they were being left out in the cold again – this time not so much for the facts, but the tone of Microsoft's message. But then something happened. WinJS didn't really pick up as expected; the majority of apps in the Windows Store were created with XAML. Obviously, developers weren't happy and were loud enough to be heard, so when Windows 8.1 was announced, an interesting shift happened. If you look at the sessions of Build 2014, you'll see that the focus was again on XAML, not on WinJS, especially for LOB applications.

During the previous year, rumors claimed that the WinJS team would target developers who wanted to build branded, unique experiences, and that the XAML group would target businesses and developers trying to build standard applications (following the Microsoft guidance and development templates). Or, in other words: B2B = XAML & C#. After all, investments were made, and Microsoft didn't want to leave all those developers unsatisfied.

From that, we at least know that Microsoft listens to its developer base and is keen on keeping the ball rolling with investments in XAML. But there's one more thing to take into account: the platforms that utilize XAML. The last few years have seen a definite shift to mobile applications -- and, frankly, Microsoft is still a rather small player in that regard.

XAML now

While on the job, I work on a lot of RFP's from potential clients – from those, the shift to mobile (even for enterprise and LOB applications) is obvious. At the same time it's obvious that, in lieu of the current BYOD trend, those applications must, at the very least, run on both iOS and Android. The reality is that for many potential clients, Windows Phone is often an afterthought – so, what good is a vendor investment in a technology if the demand isn't there yet?

Rewind about six months ago.

Xamarin (allowing cross-platform development in C#) became a Microsoft partner and shortly after that, Xamarin Forms came along. To be honest, I wasn't much of a fan of the initial release, but that changed. In essence, Xamarin Forms allows us to build compiled to native applications for Android and iOS using nothing more than XAML and C#. In my book, that's huge, as the target market for XAML and C# suddenly became much larger.

And that's where we are right now. The go to choice for Windows desktop applications is WPF. The majority of Windows Phone and Windows Store applications are built with XAML and C#, even more so for business applications. And to top it off, we can now build applications for iOS and Android using XAML and C#.

Bottom line: The future for XAML developers is very bright indeed.

If you're interested in learning more, check out my latest course, XAML Jumpstart: Getting Started with XAML.

Ready to test your skills in Software Concepts? See how they stack up with this assessment from Smarterer. Start this Software Concepts test now.