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.