Question: XAML Flavor, Architecture & Roadmap

[robloo]

Summary

Is this project going to stick exclusively with the Xamarin Forms flavor of XAML? Is there any chance of adopting the "real" XAML from WPF/UWP? (TextBlock instead of Label, StackPanel instead of StackLayout, etc.) XAML Standard really should have been implemented by now.

If this is built on Xamarin Forms, what are the commitments in terms of bug fixes? Xamarin Forms is notoriously difficult to work with in an advanced way because of bugs and the complexity to fix them. The architecture is non-ideal for custom controls as well.

Honestly, I would like to use a Microsoft-backed cross-platform UI framework but Xamarin Forms is a poor choice for stability and the XAML differences from WPF/UWP. Other options, like the Uno Platform, are more attractive for these and other reasons.

Can you provide a detailed summary of this new framework architecture (is it just re-branded Xamarin Forms?) and a roadmap of where you are taking this in the future? I don't think this framework is what developers have been asking for but want to be sure before making decisions about current and future applications.

[dhindrik]

It is a rebranding of Xamarin.Forms, or if you want, the next version of Xamarin.Forms.

I think it is a little bit strange to talk about XAML flavor, it is not the XAML flavor that is different, it is the object model. XAML is just a markup language to instantiate objects.

And for example, the name StackLayour is logic, because it is a Layout and has Layout as it's base class. We also have FlexLayout. Maybe Grid should have been called GridLayout as well because it is also a Layout.

[nikolalukovic]

@dhindrik Strange in which way? A considerable amount of people in community find the XAML implementation in Xamarin severely lacking and impotent compared to WPF/UWP. If this project is a real push towards cross-platform support than I honestly believe the community needs proper and rich tools(like aforementioned XAML implementation from WPF/UWP) to broadly use this project in the future.

[Panda-Sharp]

+1 for UWP/WPF XAML dialect

[MartinZikmund]

If it at least gets rid of WidthRequest and HeightRequest, it would be amazing

[michael-hawker]

It seems like a good time to try and align more with the rest of the XAML ecosystem. Would make it a lot easier for folks learning and working with different projects/technologies to apply their skills.

[dpaulino]

One of my biggest confusions when starting to use xamarin forms was why does Microsoft have WinUI/WPF xaml dialect and another dialect in xamarin. It was confusing for me. If Maui could move towards WinUI xaml dialect, it would make the user experience of developers switching between the platforms much smoother.

[billhenn]

I second that... coming from a WPF/UWP background, it seems silly to have another dialect of control and property names when there is so much similar functionality between those and XF. This could be corrected and aligned per the XAML Standard idea with Maui.

[weitzhandler]

I'd only consider MAUI if it's fully UWP/WinUI compliant, that also means full WCT support.
Sorry but it's a deal breaker to me.

And it's not just because of the XAML unportability, it's because of the XF UI object model that was initially architected as mobile-centric, and lacks a lot of desktop I/O features and desktop-related APIs. I totally second what @dhindrik said, XF's XAML is diverged in a much deeper level than XAML aliases.

UWP and WinUI in the other hand, were designed to accommodate for any type of device or screen size from day one. Plus it's Fluent compatible.
This is the one good memory to keep of Windows Phone, where MS engineered it properly taking desktops, tablets, phones and all kinds of devices into account.

[tomasfabian]

There was an attempt to create a XAML Standard:
https://github.com/Microsoft/xaml-standard

even a (currently unlisted) nuget package Xamarin.Forms.Alias used to exist for WPF like Xamarin.Forms Xaml

[bmacombe]

Maybe it would be possible to leave the the XF XAML in MAUI initially, but hidden from the editor, etc. So MAUI xaml could align with WinUI better, but not break existing XF apps that are ported.

[weitzhandler]

@bmacombe please don't.
2 XAMLs are already too much (it's kinda 3 cuz WPF is not completely UWP XAML).

[bmacombe]

@weitzhandler My thought was to deprecate all the old XF XAML and leave them for a period of time to allow easier porting of existing XF apps. I have a rather large one that I'd like to not have to edit every single XAML file to port. But maybe that could be done with conversion tooling instead of leaving the old syntax, which would be fine with me.

But I suspect the current XF xaml will remain, MAUI already seems like a ambitious project to complete while working on another major XF version and supporting XF with current resource levels available.

With XF being retired and only actively supported for a year after MAUI release, they will need to make the XF -> MAUI process manageable.

[bmacombe]

@weitzhandler Thanks, but I understand the difference. I'm fine with leaving XF xaml alone, but it seems to be a big issue to a lot of folks. I just wonder if some small changes could be made to make it seem more normal to people used to UWP/WPF. Without making it code compatible with UWP XAML. But I would suggest that any XAML changes be low priority, so much bigger and high impact things to improve that I'm excited about.

[LanceMcCarthy]

This is an unprecedented opportunity to finally break away from Xamarin.Forms XAML and use the XAML that everyone knows well.

I understand the original rationale that you wanted it to be familiar to Android and iOS devs to get them to use Forms, but we're past that now. If you're going to ask them to learn XAML might as well learn the standard names for elements at the same time.

For starters:

• StackLayout => StackPanel
• Entry => TextBox
• Label => TextBlock

However, we can't stop there, the functional properties need to be re-named as well:

• WidthRequest => Width
• HeightRequest => Height
• HorizontalOptions => HorizontalAlignment (and remove the extra confusing options.e.g. Fill is supposed to always fill and expand)
• VerticalOptions => VerticalAlignment

etc.

Here's a repo to try and align some of the suggestions (fix and suggestion PRs welcome). https://github.com/LanceMcCarthy/MauiSuggestions

[Update 1 - Replaced a promise for examples with link to a repo]

[mossyblog]

Enough with the Xamarin experiment ... regress back to the way XAML worked, throw in WASM into the mix and lets get back to where we left off in 2010 - productive - but now with iOS/Android and new desktop moments ahead.

We can do this.. its the perfect time for it.

[mhmd-azeez]

This thread basically asks for Uno, this is still Xamarin Forms. I don't think they can make such a great breaking change. This is more of a re-branding.

[michaeldera]

XAML is great and would much rather have that as well and I agree with, I agree with the idea of breaking away with Xamarin. Project MAUI is a an exciting opportunity to further develop it..... It was designed with different size devices in mind so it would be great to use that.

It would have been great for the FluentUI on Web controls to actually match those in XAML as well.

[martinsuchan]

I really, really hope that the MAUI XAML Flavor gets Compiled Bindings (x:Bind) from the UWP XAML framework. It's such a major step forward comparing to classic, run-time Bindings in WPF/WP/Silverlight.

[kipters]

I'm on the sentiment of everyone else: not supporting the same dialect as UWP/WinUI is a dealbreaker for me (including x:Bind)

[MartinZikmund]

I really, really hope that the MAUI XAML Flavor gets Compiled Bindings (x:Bind) from the UWP XAML framework. It's such a major step forward comparing to classic, run-time Bindings in WPF/WP/Silverlight.

Compiled bindings are supported already by specifying x:DataType (https://devblogs.microsoft.com/xamarin/compiled-bindings-xamarin-forms/), but having this based on Binding vs. x:Bind would be preferable.

[dhindrik]

I think Xamarin.Forms way of doing compiled bindings is much better than the UWP way. I don't like that I have to specify a "ViewModel property" in the code behind when using x:bind. To set x:DataType is a great way and I think it is much easier to understand for new developers.

MAUI will not be XAML only, and also Xamairn.Forms started with C# only. So I don't think we should talk about XAML, let's talk about how we can create a good object model. Because XAML is just about instating object. So I think it is pretty weird that the namespace for UI elements in UWP is Windows.UI.Xaml. It should be just Windows.UI

[jonathanperis]

Please use this opportunity to unify these markups. If project MAUI is an "phase out" for xamarin, there's no better moment to do this. Wpf's XAML is far mature and well known by the community. If your intention is attract both windows and mobile developers, give them both good reasons to go full head into MAUI

[tomasfabian]

MAUI will not be XAML only, and also Xamairn.Forms started with C# only. So I don't think we should talk about XAML, let's talk about how we can create a good object model. Because XAML is just about instating object. So I think it is pretty weird that the namespace for UI elements in UWP is Windows.UI.Xaml. It should be just Windows.UI

@dhindrik as @Emiliano84 already pointed out - we are basicly discussing about XAML dialects. Instantiantion of objects mainly of UI Controls etc., common to all targets. Basically we would like to have a standardized XAML dialect based on WPF or WinUI if it is possible.

---

Based on my experience lot of (not all) iOS and Android developers consider Xamarin.Forms as evil. In practice probably WPF/UWP developers are taking advantage of Xamarin.Forms even more then newcomers from iOS/Android. I consider this as an argument why MS should prefer WPF/UWP dialects over Xamarin, even if MAUI is evolution of Xamarin.Forms as stated in readme. WPF XAML dialect is a good mature candidate.

[legistek]

I've said in other issues but will repeat here -

I'd like to see a totally new set of classes under a System.Maui.Presentation namespace - maybe even its own Nuget package - mapped to http://schemas.microsoft.com/winfx/2006/xaml/presentation with the same names and hierarchical structure as WPF or UWP (doesn't really matter which but just pick one and be consistent; we don't need yet another variant that doesn't deviate in substance). Everything from FrameworkElement down to DataGrid. These would all be lookless / templated controls rather than use native renderers. Obviously things would be implemented over time, many by the community potentially.

For compatibility they can keep everything currently in Xamarin.Core mapped to http://xamarin.com/schemas/2014/forms and keep them using the native rendering system.

Then people can choose which they want to use and potentially mix and match using XML NS prefixes.

I don't even think this has to be an official part of the Maui project as long as certain barriers are taken down, like the hard-coded reliance on http://xamarin.com/schemas/2014/forms as the default NS and many classes that are impossible to subclass.

[dotMorten]

Personally I think it's fine that there are some differences between the object models. Building cross plat creates some interesting problems, like not all buttons can contain whatever content, so a Text property makes sense instead, as all platforms can handle that.

However I do not think that things that are literally the same should be different like TextBlock vs Label, BindingContext vs DataContext, Click vs Clicked event etc etc.

It is also frustrating to see that Forms has continually been adding stuff that diverges even more from other platforms instead of trying to align on at least all new things.

Look I get it... They want to evolve, but they should do so together with the other xaml teams and through common designs. There really should be a xaml/.NET UI API design board covering all flavors.

[legistek]

Completely agree.

I used to be apoplectic how UWP XAML diverged from WPF. And on the most irrelevant things, like WPF requiring "clr-namespace" and UWP using "using". That one little stupid thing made it impossible to share XAML between them. So what did I do? I stopped caring about UWP and dropped it,

[thomasclaudiushuber]

I think the problem is that XAML is just a serialization format with some magic on top, like Markup Extensions and Type Converters. The elements as such are not part of XAML, they are part of the UI framework mapped to the default xmlns.

So, it's more about aligning UI frameworks than aligning XAML (of course, there are XAML-specific features like x:Bind etc.).

This means that the XAML Standard was actually not really a XAML Standard, it was more a UI Framework Standard that tried to align the underlying UI frameworks and their class names / object models.

I agree that it would be much simpler (for WPF/UWP devs) if we would have at least the same names for the same things, like BindingContext vs DataContext, BindingProperty vs DependencyProperty.

And yes, I dream that I create a .NET 5 UI library that is not UI framework specific. In that library I build controls with XAML, and I reference the library in Xamarin.Forms, WPF, UWP, WinUI, and it just works.

But on the other side I know that this is hard. And there are many features in Xamarin.Forms that are different, and some are also more powerful compared to UWP/WPF. Let's take Styles as an example. In Xamarin.Forms, you have things with XAML Styles that don't exist in WPF/UWP: ApplyToDerivedTypes, CanCascade, BaseResourceKey, Style Classes, to name a few.

All these special things make it very hard to align the underlying object model with the one from WPF/UWP. And aligning dialects and especially keep them aligned means also that there are many meetings with other persons, and this might slow down the development of MAUI.

What you should also not forget: There are also many non-WPF/UWP developers who switched to Xamarin.Forms. Introducing the WPF/UWP object model to MAUI would make it really hard for them, as they know just XF, but not WPF/UWP. So, while it's good for win devs, it might be not so good for devs who know only XF.

I think the best thing to do is to continue with the object model of XF as it is, evolve it to MAUI, and improve it in the future. This allows the fastest way to adopt to the market. Let Maui sit on top of iOS, Android, WPF/WinUI. We often try to see Xamarin.Forms as a side-by-side product to WPF/UWP, but actually, it sits on top of it. WPF/UWP is for Xamarin.Forms just a single target like iOS and Android. From that perspective, Android developers could also say: Hey, we should adopt AXML to create Xamarin.Forms UIs.

To be honest, I understand if it's not aligned. My wish is that Maui becomes really great for desktop apps. Then I might just chose Maui for my new WPF/WinUI project instead of native WPF/WinUI XAML, even if WinUI is my only target. Then there's no need to learn 2 XAML dialects for most applications.

[tomasfabian]

@thomasclaudiushuber as I stated before Xamarin.Forms users are probably mostly WPF/UWP developers not Android/iOS devs. They do not like Xamarin at all. In "The jorney to One .NET" Scott Hunter says that the most newcomers to .NET are students.
Does MS have statistics about the devs using their products (Xamarin in this case)?