Beginners Question: Are UWP, WPF and Xamarin.Forms not the same?

[SetTrend]

I'm currently learning UWP and Xamarin.Forms, beginning with UWP.

Until a few moments ago I wasn't aware that UWP, Xamarin.Forms and WPF apparently don't have much in common, except they rely on XML as their markup language. I believed that XAML was sort of a "standard" spanning all the products. Yet, a few minutes ago I received an answer on GitHub and an answer in the Xamarin.Forms forum telling me different.

😟😥 Sigh ... To me that looks much like tripling the effort of learning UWP, Xamarin.Forms and WPF altogether if they all go into different directions.

Do you know, is there perhaps a strategic effort on the way keeping all three flavors in sync?

[Felix-Dev]

@SetTrend WinUI (UWP) XAML and WPF XAML flavors will probably never be fully aligned. What we could see is that new features like simplified Grid Column and Row definitions will be added to both WinUI and WPF in the future (and MAUI perhaps as well - the successor to Xamarin.Forms).

WinUI Desktop will also bring over UWP XAML to Win32 apps without devs having to explicitly use the current XAML Island technology, so for new UWP or Win32 apps, you would ideally use the same XAML flavor in the future once WinUI 3 has been released. With WinUI being the leading native UI platform on Windows (in terms of investments), in the future there should be less and less reasons to pick WPF over WinUI for new Win32 apps. The WinUI team is also working on bringing over missing WPF features to WinUI to help close the gap between these two products.

UWP XAML and WPF XAML do have quite a few similarities (more than with Xamarin.Forms' XAML flavor) but they also have some essential differences: @robloo Created a detailed overview about differences between them and what the alternatives available are here.

As for Xamarin.Forms: That product is being supeceded by MAUI and the community has been passionately asking for MAUI to align itself with the UWP (WinUI) XAML flavor where it makes sense. If, and to what extend the Xamarin.Forms/MAUI team will act upon that request is unknown as of yet to my understanding. An issue listing specific XAML alignment proposals can be found here.

[StephenLPeters]

@ryandemopoulos FYI

[ryandemopoulos]

Yes, it is indeed confusing and there's definitely no shame is asking how these technologies relate. :) It can make your head spin!

The first thing to understand is that there is XAML "the language", and then there are UX framework that use XAML "the language" as a mechanism for specifying the UI elements of those frameworks. Each of UWP, Xamarin.Forms, and WPF is a separate UX framework--the elements you specify are different. Even though each one has a <Button>, they are different implementations of a <Button> with basically nothing shared between them.

Each of these UX frameworks uses it's own variant of XAML "the language" to specify the arrangement of these elements. The WPF and UWP XAML variants are fairly familiar (they share a common historical lineage), but there are differences between them--they aren't exactly the same. Some of these differences are due to differences in the underlying capability of the UX framework; for example, x:Bind is a UWP XAML feature that doesn't exist in WPF framework, so naturally that isn't a part of the XAML that WPF uses to describe it's elements. Xamarin.Forms' XAML is quite a bit different than these other two, with many differences.

The good news is that WinUI 3, which is under development as a standalone UX framework that basically is just the UWP XAML framework lifted out of Windows, will not add a new flavor--it just picks up where UWP XAML left off and continues to advance that variant.

Hope that all makes sense and is helpful. :)

[robloo]

@Felix-Dev

As for Xamarin.Forms: That product is being supeceded by MAUI and the community has been passionately asking for MAUI to align itself with the UWP (WinUI) XAML flavor where it makes sense. If, and to what extend the Xamarin.Forms/MAUI team will act upon that request is unknown as of yet to my understanding.

At this point, I get the impression that Xamarin.Forms/MAUI is moving away from XAML long term (although it will still be supported in more of a maintenance mode). They are putting a lot more investment into their version of 'MVU' and writing UI from code directly instead of markup. There are certainly pro's and con's with both approaches but I can't help but think: wasn't markup created to solve the issues related to writing UI from code? Has the new generation really forgotten what was learned in the 90s/00s? Are we going in circles? That said, one-way flow of data and accessing the view model directly when building UI is good -- but this can all also be done in XAML with a blazor style approach, one-way data binding and modifying the model from events (instead of two-way binding). (apologies for going off-topic)

@SetTrend

All of this is to say, I would consider Xamarin.Forms/MAUI as it's own, separate dialect and going its own direction and likely away from XAML long-term. So if your goal is to use Xamarin.Forms in a mobile scenario you might not want to focus on XAML exclusively. If the goal is WinUI 3.0 (and legacy WPF) then the dialects are similar enough you can probably copy-paste 95% percent of most code and most tutorials are usable for both.

[SetTrend]

Thanks a lot for enlightening me, guys 👍

Much of this information is new to me. Let me try to reconcile my current observation from your replies:

I may be wrong, but the following statement seems the boiled down result of what I learned from you today:

It pretty much looks like there actually is no such thing like "XAML" (aka. "XAML language"). A construct like "XAML" doesn't exist. It's just three distinct UI frameworks, non-related whatsover, incidentally each using plain XML for describing their views.

Each of the UI frameworks could as well have chosen JSON, YAML, Blazor, C# or INI files to describe their view structure since all they do is to transpile the textual view description into their UI framework's .NET classes anyway. It's a pure coincidence they all use XML for describing their views and calling that XML "XAML".

So, if one of the three UI frameworks decided to rename a <Button> element into <Burton> element or invent a new strategy of navigating, that'd be fine because "XAML" doesn't impose any constraints on anything.

Please don't get me wrong, I'm not judging here at all. I'm just trying to get things clear in my mind to be able to drop existing misunderstandings.

So, if I got you correct, XAML is just a marketing jib but not a real semantic construct at all. It could as well just have been called "XML", but that wouldn't have perceived by the audience as sort of an invention.

Up until now I believed "XAML" was some base framework all the UI frameworks base upon. But that doesn't seem to be the case. "XAML" is actually, from your experienced perspective, "nothing". And the three UI Frameworks UWP, WPF and Xamarin.Forms have nothing in common.

... Am I right with this assumption?

---

Nonetheless, @robloo, thanks a lot for pointing to this very interesting blog regarding MAUI.

After reading the blog and Scott's strong statement:

.NET MAUI simplifies the choices for .NET developers, providing a single stack that supports all modern workloads: Android, iOS, macOS, and Windows. The native features of each platform and UI control are within reach in a simple, cross-platform API for you to deliver no-compromise user experiences while sharing even more code than before.

That strategic idea sounds very intriguing to me. If that'd be true, this would save a lot in spending resources on learning and maintaining different UI frameworks.

If that's really the intention: "one .NET to rule them all", then I wonder why we don't drop all other UI frameworks (incl. UWP and WPF) and just use MAUI for them all.

In the end, it's all just about front-end programming. All the frameworks claim to fit on every device. There can hardly be any GUI element that cannot be represented on any device and any OS today. However, platform specific controls, like DirectX controls could be added as platform specific packages to a MAUI solution.

Shouldn't MAUI then better be the base framework for UWP, with UWP just providing one or two additional extra packages with OS specific controls, like DirectX controls? (Thereby actually dropping the idea of UWP and just adding a few additional, platform specific controls to the System.Maui.ControlGallery.Windows namespace?)

[robloo]

It pretty much looks like there actually is no such thing like "XAML" (aka. "XAML language"). A construct like "XAML" doesn't exist. It's just three distinct UI frameworks, non-related whatsover, incidentally each using plain XML for describing their views.

So, if I got you correct, XAML is just a marketing jib but not a real semantic construct at all. It could as well just have been called "XML", but that wouldn't have perceived by the audience as sort of an invention.

XAML very much exists and is more-or-less standardized. It is simply a language, based on XML. However, the object model that language describes is very different and separate. So XAML is the same, object model is different.

So, if one of the three UI frameworks decided to rename a element into element or invent a new strategy of navigating, that'd be fine because "XAML" doesn't impose any constraints on anything.

Yes! As you point out the XAML syntax is the same with <Button> and <Burton> but they are creating two entirely different objects -- one Button and one Burton.

The evolution of the UI frameworks, and their object models, is below. There is no 'base' framework as there are historically three completely separate implementations. Only the Microsoft branch has a somewhat logical evolution though.

• Xamarin : Xamarin.Foms -> MAUI
• Microsoft : WPF -> Silverlight -> UWP -> WinUI

(Note Silverlight was a rewrite in C++ instead of managed C# code and lost a lot of features in the original WPF. Overall we have still not gotten to the point where UWP is as powerful, stable and feature-complete as WPF. However, WinUI is attempting to fix those wrongs now and later versions of UWP were getting close while providing better in-box controls.)

Xamarin was a separate company before being purchased by Microsoft. They purposely made changes to the XAML/object model so they wouldn't get sued by Microsoft and they also thought they could do things better. I suggest reading though dotnet/maui#43 as @Felix-Dev suggested in some detail to know the full history. The Maui object model is so much more inferior compared to WPF/UWP its almost not worth discussing though. It should not exist in my opinion and making it part of .net where WPF already exists - with a completely different design - is a big strategic mistake. It creates a big confusion for new developers like yourself and a major frustration for even experienced developers who have existing code that depends on existing features (even basic features like putting an symbol inside a button).

If that's really the intention: "one .NET to rule them all", then I wonder why we don't drop all other UI frameworks (incl. UWP and WPF) and just use MAUI for them all.

This is the biggest frustration with Microsoft right now. Microsoft is a big company and there are lots of independent teams. High-level leadership in this space seems to lack a vision as well. We are now seeing a result of this. WinUI is on the right track. Maui.... well... a lot of us don't see how its a good idea.

So explain how MAUI is now the cross-platform standard instead of historical Microsoft tech? (rhetorical) It's a bad decision on Microsoft's part for a number of reasons including the basic architecture. Maui translates to native controls on each platform instead of rendering on it's own surface or rendering pixel-perfectly on top of platform primitive controls. This means you will never get complex UI to work correctly on all platforms without writing custom renderers. It requires constant tweaking and ignores the modern convention to create consistent UI on all platforms.

Microsoft's fragmenting of the ecosystem and inability to standardize XAML/object model between WinUI and MAUI teams is concerning. We tried to warn them of it but the Xamarin team is quite smug about such things and feels they know best. Where they are now is also a product of past decisions and the desire to maintain compatibility. However, in practices it represents an inability to understand developers want a unified system that runs everywhere but is consistent with what we already know -- and maintains full power. MAUI is advertised as being such a system. However, its architecture is so bad I don't think it will ever get there.

It will always frustrate me Microsoft pulled in Xamarin.Forms into .net itself and claimed it as the future, single cross-platform solution Maui. Instead I would encourage the use of Uno Platfom + WinUI for apps that truly run everywhere (including the web browser). It is using the latest XAML from the true Microsoft branch and is architectured in a way it maintains almost full power.

[SetTrend]

Excellent and very informative comment 👍❤

[saint4eva]

@robloo what do you mean by Maui is not a good idea?

[robloo]

@robloo what do you mean by Maui is not a good idea?

@saint4eva I probably got a little carried away with that statement. I'm also biased having seen the evolution of this type of technology from the beginning picking it up back in WPF. However, the main disadvantages:

1. It's a new object model that differentiates from the past in a number of key areas (for more bad than good I would argue). There are really too many differences to describe but things which were so basic in WPF such as generic content in buttons or even gradient brushes don't exist.
2. It started out, at least originally, as a least-common-denominator architecture. It only translates to native controls which means if a control or feature didn't exist on ALL platforms its not in Xamarin Forms (which is becoming Maui).
3. As mentioned, the architecture translates to native controls which means it isn't pixel perfect on all platforms. For simple form-entry type apps this is fine. But as soon as more complex UI scenarios or styling customization are required things break down as the developer's hands are tied. There are several examples of this that can be dug up in various issue reports.
4. There is disagreement, but a lot of developers want to write an app and share a UI styling more-or-less across platforms. That simplifies development and testing for a lot of small, medium and even some large apps. It's similar in concept to web technology where everyone can style as they see fit. With XF you are stuck with the native styling and extensive validation on each platform.
5. Relating to number 3 and 4, a flutter-type architecture is widely considered the best right now (although that was debated for a long time). A flutter-type architecture renders everything itself.
6. WPF is already part of .NET. However, now Maui is being made part of .NET with a completely different object model and architecture and we are told it's the future. This is strategically a mistake for a number of reasons. Some of the biggest:
   • It causes fragmentation
   • It creates confusion for new developers
   • It is a major frustration for experienced developers who have existing code that depends on existing features
   • It doesn't align with the WinUI object model either