Question: XAML Flavor, Architecture & Roadmap about maui HOT 205 CLOSED

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]

from maui.

+1 for UWP/WPF XAML dialect

from maui.

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.

from maui.

@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.

from maui.

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.

from maui.

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.

from maui.

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.

from maui.

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.

from maui.

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.

from maui.

It would be an incredible blunder and a real shame if MSFT didn't take this chance to revitalize XAML and unify it under one flavor(UWP one would be the best imo).

from maui.

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

from maui.

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

from maui.

Yes, people can't blame MSFT for XF not having the same XAML syntax of WPF or UWP. It was born inside another company. But now that MSFT owns Xamarin, it makes totally sense to merge everything and come up with a single XAML flavor. And Maui seems to be the perfect opportunity for it.
@PureWeen @StephaneDelcroix @davidortinau

from maui.

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.

from maui.

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.

from maui.

@PureWeen, I wanted to offer my perspective. My company has been making commercial UI controls for Microsoft UI platforms since WinForms first came out. Of the XAML-oriented frameworks that have been released, we have focused on WPF, Silverlight, and UWP and have extensive experience with all of those.

We never made the jump to Xamarin, because it seemed to have a significantly different set of control and property names/features (StackPanel vs. StackLayout, Width vs. WidthRequest, etc.) that couldn’t be easily maintained in conjunction with our other WPF/Silverlight/UWP codebases. Whereas with Silverlight and UWP, they could be kept relatively in sync with our WPF codebases using various #if blocks where needed. While Silverlight is out of the picture at this point, we are still actively doing daily development on WPF and UWP. Even between WPF and UWP there are annoying things that are supported on one platform but not the other. For instance, UWP originally came up with a different way of xmlns using syntax and didn’t use XmlnsDefinitionAttribute. UWP doesn’t support dependency property coercion. Whereas WPF doesn’t support the faster x:Bind mechanism and until recently, didn’t have access to newer APIs added to Windows. WPF doesn’t have advanced support for handling modern input devices like UWP. Yet UWP projects take many times longer to build than WPF projects, which wastes productivity time. And UWP’s .NET Native was a disaster since there would be bugs that would only show up in .NET Native compiles that never occurred during debugging. This lead to having to make Runtime Directive (rd.xml) files to work around these random bugs introduced by .NET Native. All said and done, after years of experience in multiple .NET UI platforms, we find that WPF is the most enjoyable and productive one to work in. The problem is obviously that while it’s great for desktop apps, it’s never going to support mobile.

My dream has always been to have a XAML and C# oriented UI platform that is well supported by Microsoft and open source community, targets mobile (and ideally web) platforms, and maintains the naming/features of the existing XAML UI platforms already created by Microsoft. I believe the latter was the goal of XAML Standard. I’d love to see MAUI either pick WPF or UWP control/property naming and run with it. As many others have said above, this is the time to get things aligned properly and encourage other XAML developers to want to jump to your platform.

As far as UI appearances go, I think you’re always going to find that some people will want to have a “native” look across platforms, and others who want a totally custom theme that is consistent across platforms. Based on what we see coming out of major apps these days, it seems the consistent design approach is more popular and is personally what I would prefer to have supported if we could only pick one way. That was another reason we never made a move to Xamarin since it seemed focused on maintaining different looks on each platform.

In regards to custom theming, it would be great to have MAUI support control templates like in WPF/UWP with very fast rendering performance. And the ability to custom draw in code with high performance as well, similar to when we use Win2D in UWP or WPF’s DrawingContext.

Another important thing for control developers like us is to not close off classes/methods by sealing them. From what I’ve read, Xamarin seemed to do this a lot. The MAUI platform needs to be as open and extensible as possible, especially so that it can evolve in the future to support other devices we haven’t thought of yet.

We really want to see this done right so MAUI can be the “final” XAML oriented platform instead of a new flavor popping up every several years. Settle on something solid and let it be iterated on and evolved properly. Flutter seems to have a ton of positive momentum attached to it. This is Microsoft’s one chance to get things aligned properly for the future and to attract the .NET devs to use their platform instead of jumping ship to Google’s. I’m sure there are a ton of developers here in GitHub ready to give support.

from maui.

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.

from maui.

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.

from maui.

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

from maui.

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,

from maui.

Impressive work indeed.
The final bummer that had me leave XF was when they announced Shell I was so anxiously waiting for, then it came without UWP support.

Anyway, sorry but to be honest, with Uno on board, I'm not considering to switch back to XF. I never liked its object model. Always felt to me like a bunch of patches and fixes, where the UWP/WinUI object model is pre-thought and engineered right from the beginning.

And let's not forget, Uno IS Xamarin. It's Xamarin.iOS and Xamarin.Android, just not Xamarin.Forms. Uno is what XF should have been in the first place. Xamarin.Forms came in and reinvented the XAML wheel, to me, in a bad way.

My favorite is UWP/WinUI XAML, but as mentioned around, all missing WPF features should be brought over, like binding types, markup extension services etc.

from maui.

This all really does beg the question of why not to just use Uno. If not for my bias toward official Microsoft technologies I probably would have taken that plunge long ago. I wonder if it wouldn't make more sense for Microsoft to acquire Uno and call that .NET UI. The Xamarin iOS and Android backends are still hugely valuable (and used by Uno) and Xamarin Forms itself can always remain as a RAD tool for cross platform mobile apps but I do get the feeling that the XF codebase might just be too far off to ever evolve into what many of us in this thread really want.

from maui.

Wait... Why are we even talking about XAML? It's ancient XML! While most prefer Wpf/UWP to WinForms for development, it's not the XAML markup they like--it is the target model and its ability to interact with it expressively. Working with XAML is painful and tedious, but we like it because it beats working with HTML. It would have never gained much popularity if Blend wasn't such a disaster. Blend was so slow and cumbersome, it was always easier to write the XAML directly. Blend/XAML could have been the PostScript for GUIs, where its tooling is so good, billions of users use it everyday but have never seen a line of its code.

All that said, why not circumvent all this handwringing and just use JSON! Alan Kay said, "If you want to look at the future, look towards the past." It's hard not to see it as a reincarnation of the old resource (RC files) with clear advantages over XML markup:

• Less verbose, compact and light weight
• Network friendly (UI definition can live on a local server or on the cloud)
• Serializes and deserializes faster and easier (MacOSButton.Deserialize(stream))
• Less cluttered and easier to see structure
• Easier to read, learn and edit by humans
• Friendlier code generation (Adobe Illustrator and Sketch plugins)

JSON could solve one of the biggest issues with cross platform development. If you defer the platform specific behavior and appearance to JSON, then creating a separate markup file for each platform doesn't become as onerous as working with XML. If well implemented, it can be done by designers and purely frontend folks.

from maui.

@PureWeen You've essentially confirmed my suspicions that Microsoft is going on a tangent with MAUI and I should be looking to other technologies -- at least for the next few years until .net6 or 7. How do you have so much developer feedback here asking for one thing yet you are internally justifying something else? I don't mean any disrespect, but do you use your own products? Do you have developers left from the WPF/Silverlight days?

@BillHenning says it about as good as I can:

We really want to see this done right so MAUI can be the “final” XAML oriented platform instead of a new flavor popping up every several years. Settle on something solid and let it be iterated on and evolved properly.

WPF was ground-breaking technology when it was released. It blew away everything else on the market. Since then, instead of using it as a base, you keep re-writing it and needlessly changing things. Developers can't/won't follow this strategy; because, well, it isn't a strategy. You are fragmenting the ecosystem. Each time you make a change you also loose functionality.

Adopting winui/uwp/xaml doesn't all of a sudden make Android have more features.

There clearly is a disconnect in our lines of thinking. I'm not asking for a least-common-denominator architecture which is what Xamarin.Forms is. I'm asking for an architecture much closer to the Uno Platform. They've solved these problems in a way that works with native controls. I can still put an image inside a button although iOS doesn't support that. They do not simply translate to the native control properties.

All of the drawing/shape/path APIs that we are adding to forms match WPF/UWP drawing 1:1 so as those land you will be able to do all of those things.

That is cool!! I don't mean to be all negative. But take that same type of thinking to the rest of the UIElements now.

I think there is still a mismatch in my head from what everyone is expecting will happen if we make our XAML flavor match UWP. If we make our XAML match UWP there will be literally zero increase in functionality. It won't cause .NET Maui to just instantly have more features

What will add functionality is if we focus on adding functionality.

NO ONE here is saying don't make improvements. Most here are saying don't needlessly change from past convention. The two are not mutually exclusive. Please don't try to tell me the new object model is 'better' than WPF/UWP. The fact that Button has a Text property instead of a Content property is case closed in my opinion. I can't do a lot of things that were just given to us in WPF/UWP. Precisely how will changing StackLayout to StackPanel result in your inability to make future improvements or require removal of improvements already made? (please extrapolate that thinking to the other differences noted here: #43 (comment))

If the perspective is to replicate UNO than what's the value add for .NET MAUI?

Ok, understand that there are several areas that can be improved without frustrating developers and getting rid of functionality we've long enjoyed. XAML itself is ageing. You could adopt something like this: microsoft/microsoft-ui-xaml#2499. (The Uno guys seem to really be aligned with developers)

Also realize that with look-less controls and re-templating you really don't need a lot on top of that as a framework. It's almost perfectly generic. Developers are empowered to do what they need to do.

Don't get me wrong if we could just easily make our entire XAML match uwp/winui that would be awesome but there are a lot of things we've added that uwp/winui xaml doesn't have

There's things they have that we don't have and that we're trying to fill the gap.

Great mentality, poor execution. Just rename the controls you already have and align the object models where they needlessly diverged. Then we will be back to more-or-less WPF->UWP conversion which was annoying at first but is now doable without much trouble. As for the new features you claim in Maui/XF; well, since those don't already exist in WPF/UWP, and if they are designed correctly, they won't cause an issue when porting over apps which don't use said features.

This is the cycle I keep seeing from Microsoft:

1. WPF (an engineering marvel)
2. Silverlight (WPF more or less done correctly for the browser)
3. UWP (lost more features than gained when it was first released, has steadily improved over the years though, still quite buggy compared to WPF)
4. Xamarin.Forms (An app prototyping tech that was kind-of half-heartedly created to give developers something)
5. Maui (???)

from maui.

At this point let's rewind all of this back up to @LanceMcCarthy 's comment.

If he's still interested and wants to put together a spec for the differences then we can start there or at some point someone on our side can create one against the Xaml Standard diff

Once we have that, we can break those differences out into things that are purely names and things that would require a lot of effort. For example, renaming BindingContext to DataContext has a very low level effort because they are basically the same. Renaming Button.Text to Button.Content has a high level of effort because they are completely different properties with different behavior.

From there we can start measuring the level of effort and get buy in.

Possibly do a first round of things that are purely names and have no functional difference

from maui.

@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)?

from maui.

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.

from maui.

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

from maui.

How is XAML (the language) used with different frameworks any different from c# (the language) used with different frameworks?

I think what everyone really means is the object model, and not really XAML, but XAML is where you notice it the most, because this is generally where you instantiate your UI objects.
During the XAML Standard days, Xamarin did play with an idea where the XAML parser would translate TextBlock to Label etc, but it really falls apart when you go into code-behind and the type is suddenly something else. The idea was quickly rejected. It violates what XAML is.

you aren't going to copy/paste a UWP or WPF UI XAML into forms and just have it work even if the XAML, controls, markup extensions aligned 100%.

I don't really think anyone is really asking for this, nor expecting it. The types of apps you build for desktop vs mobile are often rather different (and even if they aren't the UI you'd build would be optimized for different interactions).
What I think most of us is asking for is mainly two things:

1. Lower the bar from switching from a XAML Platform you already know, to the other, without having to relearn what things are called (helps adoption).
2. Lower the amount of brain gymnastics you have to do, when you switch between frameworks and have to remember that over here it's suddenly called something else than in that project I worked on yesterday (I think lots of us often work on multiple projects / targets). That would reduces frustation towards Xamarin, because it's the odd-one-out, considering Silverlight, WPF and UWP generally have agreed on naming for the most part. I think this is also part of why the Stack Overflow survey 4 years in a row has rated Xamarin as one of the most dreaded frameworks (not to say there isn't other things causing this, like X-plat is hard, the 3rd party tooling it relies on is finicky, VS updates often breaks developers, etc)

from maui.

probably mostly WPF/UWP developers

@tomasfabian Ok, you downvote because of data you don't know? How do you come to this assumption, just because XF is using XAML too?

I know quite some .NET web developers who use Xamarin Forms. They are .NET developers who don't have a WPF/UWP background, but are familiar with the ASP.NET stack.

Why did the Xamarin team introduce things like CSS styling if there are mostly WPF/UWP devs? That wouldn't have made any sense.

Sorry, if we don't have numbers about the background of developers, it's not really good to discuss on this level.

They do not like Xamarin at all.

That's also not true in my experience. I am a WPF/UWP developer, so I must be an exception. While UWP XAML is my favorite XAML dialect, I see there are some pros in Xamarin.Forms XAML too.

My point is: Keep XF XAML for Maui, and evolve it to the best of both worlds in the future!

from maui.

Why not align MAUI object model to UWP, WPF, WinUI and build a single UI framework to rule them all? I don't care if it breaks compatibility with current XF (which I know and love) but if it's for the better of the .NET platform, I thing it's something that worth.

from maui.

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.

from maui.

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.

from maui.

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.

from maui.

Lots of good comments! A few more ideas so far:

• It's good we are hearing valid points from both sides. I respect all viewpoints although I strongly favor keeping the same XAML/object model standard with Microsoft tech (more on that below). The fact that MAUI is now getting merged into .net itself -- with a XAML flavor different from WPF which is already in .net -- gives me a sinking feeling Microsoft isn't doing the right thing.
• Both viewpoints have the same, valid, reason not to change XF XAML one way or the other. What is best for developers is to build off of the old tech and evolve into new territory. Not completely reinvent the wheel. Now we are stuck in a very tricky position where some developers are already used to Xamarin Forms XAML and don't want to change it. Then the rest of us are wondering who in their right mind signed off on different XAML in the first place and why it's changed from the existing WPF/UWP code we have. Everybody has a point and all points are the same -- don't change what already works. Bottom line though, the ORIGINAL mistake was creating a different version of XAML. Always fix the original mistake if you want to make progress in the future. A compatibility layer to convert existing Xamarin Forms XAML would be possible.
• Speaking of evolving into new territory, I'm fine with evolving XAML (something like this: microsoft/microsoft-ui-xaml#2499). However, we can't keep creating new frameworks with less-and-less features and doing things in a slightly different way. Microsoft is needlessly fragmenting the ecosystem. Xamarin Forms was out of touch with what most developers were looking for when it was first released. Sure, people have some uses for it but the apps tend to be very basic. I'm wonder if Microsoft realizes this now and has a roadmap to make MAUI really powerful -- like Uno Platform, like what UWP should have been all those years ago.
• When I created the issue I was hoping for an official response from Microsoft. I don't think they've commented yet. That is probably a good thing as it means they are still having these discussions internally and haven't made up their mind yet.

There should just be one platform/tech, where it's used for both Windows apps AND cross-platform... Regardless of whether the convergence happens into MAUI or into WinUI doesn't really matter... however converging onto MAUI seems like the easiest and most simple approach (and then WinUI would go away).

This is what developers have been asking for from day one. For various reasons a lot of the other frameworks are not desirable for developers coming over from the desktop. For the most part the existing frameworks just aren't powerful enough -- in feature set, in control rendering capability, in performance, etc. Microsoft still has a chance here (although Uno is really close). MAUI (Xamarin.Forms right now) isn't powerful enough to be a general purpose cross-platform development platform. Simply put, the problem is the original architecture taking a least common denominator approach. This is useless for anything more than basic 'showy' apps. Therefore, I disagree with your recommendation to converge around MAUI in it's present form.

from maui.

@andrewleader agree there needs to be a one and only solution, but for it to become the one and only it has to be the one with the best architecture, which to me XF is not.

from maui.

I got a lot of downvotes on my comment above (which is great for the discussion), and as @tomasfabian pointed out, it might be mainly because of this:

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.

I thought I should add some details why I wrote that, because some of you know that I love WPF and UWP/WinUI.

The quote above is a small sentence that collides with many opinions here. And when I wrote it, I knew I won't make friends here. So, let me explain a bit more why I wrote it.

I'm a WPF/UWP/WinUI dev, and I love WPF and UWP XAML. Currently I'm also working on a Xamarin.Forms project, and yes, it's much better than what it was when I have used it the last time. I like it. But as many of you, I would love to see WPF/UWP XAML used for MAUI.

The naming differences between the Xamarin and WPF/UWP stacks are weird. There are many things I would change, like these, to name just a few (and many were already mentioned by others here):

But then, on the other side, I see so many other things that are different, and that can't be resolved with renamings. For example HorizontalOptions vs HorizontalAlignment. It's not the same, as the HorizontalOptions have the things like EndAndExpand, while HorizontalAlignment has just Left, Center, Right, Stretch. So, this is the first thing that needs a changed API to align it. It's not too hard in this case, but then when you go through the Xamarin.Forms class hierarchy, you see many another APIs that need to be changed to align it, for example, where is the Control class? (Don't answer it, it's a rhetorical question :)). And then you go deeper and deeper into the class hierarchy and you notice, it's kind of impossible to make it really clean without rewriting the whole Object Model including all the base classes. Take a look at it here .

My UWP/WPF developer heart says: Yes, this is what I want to have, so rewrite that thing. I want to build cross-platform .NET applications with UWP XAML and UWP Object Model (Hi Uno, I know you're there.).

But I see that it means actually a rewrite of the whole Xamarin.Forms stack. And at the same time I see all the improvements the team plans for MAUI, and I love them.

I think rewriting the whole stack for .NET 6 is quite hard (is it even possible?) with all the other planned and also very important features. And this is how you should understand this statement:

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 statement means not that I believe that XF XAML is the best option. I think due to the reasons mentioned above it might be the best plan to continue with XF XAML. And then, evolve it to the best of all XAML worlds in the future!

In an ideal world, it would evolve to the best of all XAML worlds with the MAUI release.

And yes, I agree, if we don't change things like StackLayout => StackPanel now, it might be much harder to change it after the MAUI release. And if a try-convert tool is planned anyway, it could do that string replace for code like StackLayout => StackPanel.

And, for the final word I quote @dotMorten

There really should be a xaml/.NET UI API design board covering all flavors.

PS: I love the passion and discussion I see here. Keep it up!

PSS: @tomasfabian I was not upset, I wanted to understand your opinion. But I see that my written words were maybe a bit too direct. Sorry for that, there was no reason for you to apologize! Thank you for your great response!

from maui.

@robloo

The first part is a great thing! Shedding the legacy and modernizing around .net6 will be quite good. Concerning "there's a huge focus on making switching to a native context much simpler" I don't understand this. Are you trying to make it easier to do things using native controls on each platform? If so, are you missing the point that we want ONE implementation that is feature complete for all platforms?

We're doing both. If a user wants to do something to a UITextField or a UILabel inline with an Entry or Label control they can just do it all right there without having to leave to a "Renderer"

If so, are you missing the point that we want ONE implementation that is feature complete for all platforms?

That's also the goal but I don't understand how this maps to the xaml conversation. How you type XAML and what something can do have no relationship with each other. The area I get the most confused about with this thread is the intersection of xaml dialect with expectations like web. What am I missing? Adopting winui/uwp/xaml doesn't all of a sudden make Android have more features.

Can I make a charting control sharing all rendering code among iOS/Android? Or do I have to write a custom render for each platform? (haven't looked as SkiaSharp for this yet) What if I need to write a more advanced control like a color picker with a field of colors to pick from? What about putting the selected color inside a button and opening a flyout to select a new color when the button is pressed? These are all common use cases but are very difficult to do in XF from what I have read. Maybe a lot more progress has been made I am unaware of. Uno Platform can do all of this -- with some bugs of course.

That's the plan. https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap

All of the drawing/shape/path APIs that we are adding to forms match WPF/UWP drawing 1:1 so as those land you will be able to do all of those things. Please look through the feature roadmap and let us know where that roadmap falls short for you

other bullet points

I think there is still a mismatch in my head from what everyone is expecting will happen if we make our XAML flavor match UWP. If we make our XAML match UWP there will be literally zero increase in functionality. It won't cause .NET Maui to just instantly have more features

What will add functionality is if we focus on adding functionality.

If the perspective is to replicate UNO than what's the value add for .NET MAUI?

Don't get me wrong if we could just easily make our entire XAML match uwp/winui that would be awesome but there are a lot of things we've added that uwp/winui xaml doesn't have

There's things they have that we don't have and that we're trying to fill the gap.

I really appreciate your response with specifics. Those are the things I'm really interested in. What limitations are you hitting with XF so that we can fix those limitations and then excel past those

from maui.

as long as there is a good transition experience from XF to Maui.

They said they'll have tools that'll do the work for you. That's simple to do if all they do is change the namespace. However I doubt it'll really work, as they are talking about more than just changing namespaces, and all your 3rd party libraries would be broken too, so an entire ecosystem also have to move too.

Personally I don't think I'd move any code from Forms to .NET MAUI (value add is pretty low), but only use it for new projects. And especially because the value-add is pretty low, I'd like to see some more significant changes made to really make MAUI worth my while. Resolving this issue would be one of those value-adds. Otherwise what's really the point of breaking the entire existing Xamarin.Forms ecosystem, if not to do some major things?

from maui.

[edited]

@Joebeazelman I don't know what happened to your comment, but I got the email notification so I will respond accordingly - I have pasted it above.
WYSIWYG is pointless with Xamarin.Forms because of the multiple device targets, screen sizes etc.
The whole point of XAML is not to create absolute layouts, but to create ones that resize according to the screen.
Absolute layouts are ancient tech from the VB6 era actually (which I was forced to use so I know all too well) and I loathe them, and so do many other people.
Whatever happens, WYSIWYG and absolute layouts should NOT be part of anything in MAUI.

from maui.

@Joebeazelman I don't know what happened to your comment, but I got the email notification so I will respond accordingly - I have pasted it above.

What happened is that it was hidden for being off-topic and potentially offensive. Please don't paste the hidden comments back into the discussion.

from maui.

@thomasclaudiushuber I down voted your message because I didn't like this statement, not because the data I don't know:
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.

I agree with the first statement, but not the rest. I apologize, I didn't want to make you upset. For me later is much better than sooner. .NET 7 sounds good, too. I had to switch the platform during my career for several times, so this time it could be better with MAUI. I'm very excited about it.

Yes I probably know different iOS/Android devs then you. They have their Flutter, GREAT Kotlin, SwiftUI etc. They don't need Xamarin. This market is (again) probably lost. Thx for your understanding.

from maui.

from maui.

Bottom line though, the ORIGINAL mistake was creating a different version of XAML. Always fix the original mistake if you want to make progress in the future. A compatibility layer to convert existing Xamarin Forms XAML would be possible.

Just in case anyone isn't aware, XF started out independent of Microsoft. It evolved from Mono which was basically open sourced .NET for Linux. Windows wasn't even a platform option for Xamarin Forms before UWP and Xamarin was never marketed as a way to port WPF apps to mobile but rather just a way to write mobile apps with C#.

So there wasn't a huge incentive to use the WPF naming conventions and it's possible - and I'm only speculating - they didn't want to get in potential trouble by doing so.

That said, now that it's all part of Microsoft, it indeed makes no sense for there to be two (arguably 3 if you include WPF v. UWP) products with different XAML flavors.

from maui.

Besides of StackPanel vs StackLayout, TextBlock vs Label and etc I don't know what is the other differences that all these xaml UI Frameworks have (sorry I was born on XF so I just know this in depth), but others on this thread that master uwp, wpf and winUI could answer.
Anyway, I think that the critical point is all about MSFT having all these different xaml based UI frameworks that are different in syntax and/or features set. It just cause confusion to developers about what of these framework should we use and when, as well as which one will microsoft focus the most in the long term and etc. I think that MSFT neeed to get one of these UI frameworks and stick with it (it could be XF - I don't know which on would be the more appropriate) and send a clear message to developers that all the efforts will be focused on that XAML/UI Framework and move on.
Having a lot of xaml based UI frameworks like we have today definitely seem to wrong direction.

from maui.

@Joebeazelman I just laugh as the rabbit hole goes further. I don't think switching from XML to JSON should really be discussed here so you might want to open a new issue. It also goes against the argument of not changing what already works -- XAML also has a few features JSON lacks from my understanding. That said, you are right the main point is to keep the object model the same. It's also a goal to simplify markup while adding new functionality. Some ideas are floating around such as this: (time 56:14) https://youtu.be/TeS4rX3i_Ls?t=3374

from maui.

I think we're deviating here about the main issue, which about the XAML flavor and architecture. Those who want something different, JSON, drag and drop, etc., could please open another issue.

from maui.

Imagine a world where my responsive XAML for my WP8.1 (RIP) app I developed a few years ago just works when I copy-paste it into MAUI project, and it just works on all platforms MAUI supports.

This is really the best time to unify XAML's (preferably based on UWP) and make major underlying platform changes. Bring back XAML Standard and continue supporting it with the community. There are thousands of contributers out there to help MS build this potentially game changer approach.

from maui.

I'm just an undergraduate student, but I'd like to share some thoughts about this discussion. As many have said, having different XAML dialects makes things like porting apps more complicated. I understand that in some cases the differences are necessary, but there are things that are literally the same but with different names, e.g., StackPanel vs StackLayout. So if there is a chance to change and 'fix' these little things, it would be great.

Now, about which flavor of XAML should be chosen, in my somehow biased opinion, I think that the WPF XAML should be the one chosen. It has the more complete XAML dialect, there is even an issue on Microsoft UI XAML repo about this. From what I've have learned so far, it seems that Xamarin Forms XAML already has many of the features missing in that repo, like binding to relative source with find ancestor mode so I think that choosing WPF would make things easier. Lastly, since WPF is more popular than UWP, this should be another reason to choose WPF XAML dialect.

from maui.

probably start with the WPF repo and adapt it to be cross platform

I know this is impractical to discuss; however, at this point, we would probably want to stick with the UWP dialect of XAML. UWP was designed with touch and small screen sizes in mind from the beginning and some of those changes are necessary. Additionally, some of the changes like x:Bind and easier translation are quite useful. Of course we should be adding back LayoutTransform, IMultiValueConverter, etc. that was lost from WPF (we'll have to live with the styling changes now).

WPF was also built with a lot more managed code and without an interop layer which in practice means it is less prone to random, sudden crashes which still happen often in UWP. My point is it would almost be better to convert WPF to UWP (with a managed implementation) and then take that cross platform.

from maui.

Why not align MAUI object model to UWP, WPF, WinUI and build a single UI framework to rule them all? I don't care if it breaks compatibility with current XF (which I know and love) but if it's for the better of the .NET platform, I thing it's something that worth.

Agree. Win UI 3 was announced and it is supposed to be a unification of UWP, WPF, WinForms. It should be a nice targeting platform for Windows

from maui.

@PureWeen This is a good approach. I made the argument earlier that Text on Button makes more sense, and things that are actually different, can be named different, and that property is a good example of that.
A while back I wrote a Roslyn-based tool that would rename types. It would have worked better if hardcoded strings had used nameof(DependencyPropertyName), but that feature was hardly used in the XF codebase at that point, but I made a short list of renames as part of the proof of concept: https://github.com/dotMorten/RoslynApiRenamer/blob/master/Xamarin.Forms/RenameList.Xamarin.Forms.txt
The neat thing about this approach is that it allowed 'my version" to stay in sync with master without worrying about conflicts, as I could just pull latest and re-run the tool. It could be useful here just to do some quick experiments with renames.

There's a good draft list here: https://github.com/microsoft/xaml-standard/blob/staging/docs/v1draft.md

from maui.

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

from maui.

There should just be one platform/tech, where it's used for both Windows apps AND cross-platform. You don't have to choose between "Do I build a native Windows app, or do I build a cross-platform app?" What if building a native Windows app WAS building a cross-plat MAUI app?

That means insanely reduced documentation (don't have to document two different things), reduced development cost, more developers all using one single tech, and by default everyone gets great cross-plat apps AND great Windows apps!

Edit: Apparently people don't like Xamarin Forms, but I'm indifferent on what platform becomes the platform, if it's UWP XAML, that's fine with me, as long as there's only ONE type of app, regardless of cross plat or native Windows!

from maui.

I admit I haven't used XF in a while since switching to Uno, but here are few, probably some of which have already been addressed: ItemsControl, CheckBox, RadioButton, Expander. I also remember having a hard time seeing keyboard and mouse for proper UX.

https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/layouts/bindable-layouts
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/checkbox
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/radiobutton
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/expander

A couple are still in preview but they will be out of preview before Dotnet Maui

WinUI is Fluent ready by design.

Can you give me examples? I Just want to make sure we're on the same "fluent page" with this one

it's about the overall design that should apply equally on all platforms by default. Native look and feel should be achieved with a theme, if desired.

We're also focused on this with upcoming XF releases and material releases. For example
xamarin/Xamarin.Forms#10773
xamarin/Xamarin.Forms#10774

And a lot of the roadmap for 4.7 => 5.0
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap

Is based around achieving these goals. Increasing the level of pixel perfect customizations

from maui.

As always @thomasclaudiushuber makes good and specific points. However, I strongly disagree in not changing to a standardized 'UWP'-based form of XAML and object model for MAUI. The arguments for standardizing are far stronger than the arguments for keeping the status quo (forgive me for speaking in general terms).

Accepting major differences like this and going forward with the current Xamarin XAML flavor and object model will do nothing but continue to fragment the ecosystem. Microsoft can't be afraid of putting in the work now (and it is a lot of work) to better position MAUI for the future and fix past mistakes. If the future developer Maui is intended to support is a college graduate that will learn fresh -- ok. However, there are far more popular frameworks that will probably win out in the end if we don't all come together around a common design. The idea for a UI XAML design board is a really good one. As it is, I don't think many existing WPF/UWP developers will switch over to Maui. It makes far more sense to use the Uno Platform.

from maui.

I am on the unpopular side. I believe there should be two variants of MAUI, one for desktop and one for mobile / web.

Desktop apps are designed differently, and solve different requirements. Who needs a floating button on a desktop app when you have so much space? Who needs a hamburger menu on a desktop app that is used for no other reason but to give you even more white space than what you already have. Do you feel having a a carousel view natural in a desktop app with a mouse to swipe? And so many other examples...

On a side note, those who complain about how "bad" XF XAML is. What should we do with the the thousands of apps built with XF? We have to open them all and rename all controls to the much loved "WPF" variant? That's while assuming "renaming" them is a flawless operation.

from maui.

I am on the unpopular side. I believe there should be two variants of MAUI, one for desktop and one for mobile / web.

Desktop apps are designed differently, and solve different requirements. Who needs a floating button on a desktop app when you have so much space? Who needs a hamburger menu on a desktop app that is used for no other reason but to give you even more white space than what you already have. Do you feel having a a carousel view natural in a desktop app with a mouse to swipe? And so many other examples...

On a side note, those who complain about how "bad" XF XAML is. What should we do with the the thousands of apps built with XF? We have to open them all and rename all controls to the much loved "WPF" variant? That's while assuming "renaming" them is a flawless operation.

@Ghasan I hear what you're saying, but there are ways around this.
I am building a no-code platform and using Xamarin.Forms for the client apps and I am having to deal with this issue - it's not as difficult as you think.
The bottom line is it comes down to screen size. So if you just detect the screen size and make code-based decisions on how to layout the UI based on that it works perfectly.
So in other words even when running the app on an iPad you see a more big-screen friendly screen layout than on a mobile phone - but it still is the same view you are seeing.
This is baked into the system I am building, and the views themselves don't have to think about it.

from maui.

Didn't mean to close :-/ some key combination I hit activated close and comment 👎

from maui.

@PureWeen

Don't get me wrong if we could just easily make our entire XAML match uwp/winui that would be awesome but there are a lot of things we've added that uwp/winui xaml doesn't have
There's things they have that we don't have and that we're trying to fill the gap.

I guess what most of us expect is that maui XAML match the same uwp/winui syntax and keep features that only XF has but uwp/winui doesn't. As well as adding what uwp/winui has that XF doesn't have.

from maui.

@robloo You're right. Thanks for helping me come to the realization. Microsoft is not about excellence. Their best products are considered merely good enough. They already had most of what's discussed here decades ago in SilverLight and WPF. The management, consisting mostly whiteboarding torture survivors, killed them off and made Windows desktop development irrelevant. It also backfired and killed off Windows Mobile as a viable platform.

Clearly, Microsoft's goal is to create a just text editor friendly XAML because they lack the vision to create something better like a WYSIWYG layout editor, like they have for Windows Forms. Why bother putting in the resources into excellence, when there's plenty of free, mediocre open source mush to sop the pigs with.

These Microsoft NET community initiatives are merely a way of obtaining free R&D from the masses of US workers displaced by H1B workers. There's a biblical proverb "don't cast your pearls to swine" and it pertains here.

from maui.

@tomasfabian we're all just speculating of course but I tend to suspect you're right. MS certainly should have statistics though! I believe they know every project type that gets created in Visual Studio. And I think the whole "Blazor syntax on Xamarin" thing is directly to your point insofar as they know a lot of devs hate XAML (irrationally IMO) and don't understand or see the benefits of MVVM and the strict separation between declarative markup and control logic.

Having grown up with WPF I like Xamarin Forms for what it has the potential to be but I haven't used it for any production projects yet. The different naming conventions are annoying but I can live with them. But the native look thing really turned me off as our application is HIGHLY designed and customized to look identical on web and WPF desktop. Most of all though I generally feel that the XF framework still isn't really robust enough yet to completely replace our WPF desktop app which is used for public presenting and so has to be super reliable and high performance. As I already have to maintain two codebases - web (Angular) and desktop - I don't want to have to have a third just for native mobile; I'd sooner adapt the web app to be mobile friendly and publish it as a PWA.

BUT if I could easily use the WPF codebase to build native mobile versions I would definitely do that. The desktop app would still compile as native WPF, but if I could reuse most if not all of the XAML for mobile then I would run separate builds to those platforms. So that's my (very much biased) motivation for a lot of what I've been pushing for.

from maui.

Xamarin.Forms.View is not remotely the same as WPF's Control. It doesn't support templating. It doesn't allow you to override input event handling behavior.

from maui.

The hierarchy is the same, and the features missing is exactly the point of this discussion around MAUI

I'm not sure which side you're advocating for, but anyway, View does not fall in the same place in the XF hierarchy as Control does in the WPF hierarchy. View is closer to FrameworkElement.

There is nothing in XF currently analogous to Control because XF relies on native rendering for visual and input behavior.

(And sorry to nitpick @thomasclaudiushuber but I'd put VisualElement = UIElement and View = FrameworkElement on your list)

from maui.

The Web version would be awesome, something that Uno is trying to achieve, though I have tried, and faced several issues in "porting" my XF app.
This would be a world class experience, having in one solution, iOS, Android, UWP, Mac and Web, all with the support from Xamarin/MS Team

from maui.

I honestly want this to rival FLUTTER framework, But again, i can see from miles away that it cant rival that kind of thing, even .net 6 would be fragmented, whereas flutter is only going forward and would be ready in complete ALL platforms notion, they even support smartwatches and more things are coming soon. where as microsoft should combine WEB and APP development like flutter and make use of WINUI (windows FORMS) design and let us create apps in an easier and better way????
what do you say?

from maui.

I honestly want this to rival FLUTTER framework, But again, i can see from miles away that it cant rival that kind of thing, even .net 6 would be fragmented, whereas flutter is only going forward and would be ready in complete ALL platforms notion, they even support smartwatches and more things are coming soon. where as microsoft should combine WEB and APP development like flutter and make use of WINUI (windows FORMS) design and let us create apps in an easier and better way????
what do you say?

Flutter Windows does not even have a Release mode and AOT yet, so Xamarin.Forms is already way ahead. Considering MAUI is an evolution from XF, I think it is definitely better than Flutter.

from maui.

Flutter is not a static concept and while essentially a v1 tech is already ranked the 3rd most loved Framework according to StackOverflow 2020 Survey:

https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-other-frameworks-libraries-and-tools

It has the full weight of GOOG backing behind it and is managed by former MSFT employees who were told to get lost when presenting their ideas within MSFT as response to our Ubiquitous .NET Client Model request.

They are highly motivated to prove themselves successful and do not have bickering within their organization on what syntax to use for their presentation/serialization model, nor do they have catastrophic, morale-sucking, and soul-crushing disasters such as the Xaml Standard occurring. Not to mention, lead developers jettisoning from efforts, etc., etc., etc., etc.

This and many other reasons is why I myself have given up on any Xaml-based initiatives of MSFT and am building my tech on Blazor these days. While not as pretty as Xaml, it is built by a much more organized, efficient, and congruent team -- a fact that is clearly demonstrated and reflected in their resulting technology. A total night/day difference when contrasted to the dysfunction on full display within Xaml-based efforts within MSFT -- which, incidentally, after nearly a full decade of effort still has problems understanding/grasping what a simple Markup Extension is! 🤦‍♂️

from maui.

from maui.

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

from maui.

@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.

from maui.

@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.

from maui.

@PureWeen thanks for your kind response, might be worth adding MS officials as members.

What are some of the main APIs that are missing for you?

I admit I haven't used XF in a while since switching to Uno, but here are few, probably some of which have already been addressed: ItemsControl, CheckBox, RadioButton, Expander. I also remember having a hard time seeing keyboard and mouse for proper UX.

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.
Same question but now about Fluent :-)

WinUI is Fluent ready by design.
XF is "native look and feel" and takes an extra step. Plus as mention earlier by other members, it's not just about fluent, it's about the overall design that should apply equally on all platforms by default. Native look and feel should be achieved with a theme, if desired.

from maui.

hello @PureWeen, I explained why is the naming important before (new/existing users adaptation). If you would ask me:

If you felt really confident about the stability and if the feature set is there would you still not use dotnet MAUI because differences in naming?

I would use it. More important enhancement for me is the direction/purpose of MAUI regarding to web targeting. Please add your comments to this thread created by @legistek. For lot of us a more relevant question is:
Should I use rather Uno platform, Flutter, something else instead of MAUI due to missing XAML support etc for web? See my post in the other thread.

Thank you, howgh.

from maui.

@bkaankose

Imagine a world where my responsive XAML for my WP8.1

Is this purely a comment on naming symmetry or missing features? What responsive XAML features are you missing in XF?

from maui.

@PureWeen Thanks for your detailed feedback! I'll be a little more specific to some of your points:

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.

dotnet MAUI isn't just a rebranding. It's restructuring of the whole native layer and modernizing around net6 features and multi targeting. It's shedding as much legacy as we possibly can so that we can simplify and focus better. There's a huge focus on making switching to a native context much simpler. No more custom renderer attributes. Ideally you'd never have to create a custom renderer ever again.

The first part is a great thing! Shedding the legacy and modernizing around .net6 will be quite good. Concerning "there's a huge focus on making switching to a native context much simpler" I don't understand this. Are you trying to make it easier to do things using native controls on each platform? If so, are you missing the point that we want ONE implementation that is feature complete for all platforms?

The architecture is non-ideal for custom controls as well.
Xamarin Forms is notoriously difficult to work with in an advanced way because of bugs and the complexity to fix them.

Can you expand on these statements with some examples? These are the scenarios we really want to simplify so I'm really curious to talk about the difficulties here

Can I make a charting control sharing all rendering code among iOS/Android? Or do I have to write a custom render for each platform? (haven't looked as SkiaSharp for this yet) What if I need to write a more advanced control like a color picker with a field of colors to pick from? What about putting the selected color inside a button and opening a flyout to select a new color when the button is pressed? These are all common use cases but are very difficult to do in XF from what I have read. Maybe a lot more progress has been made I am unaware of. Uno Platform can do all of this -- with some bugs of course.

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.

Does this all have to be boxed together? If you felt really confident about the stability and if the feature set is there would you still not use dotnet MAUI because differences in naming?

Yes, it really is all grouped together and my point is really not as petty as just naming conventions :)

• I mentioned control naming as an example but the differences are of course much further reaching than that. So examples aside, it's clearly not just naming we are talking about.
• If XF/Maui really was an awesome development framework with good stability and a nice feature set we were all comfortable with, most people would adopt to the change -- if other options didn't already exist. But your idea of where you want to take it in the future doesn't match where it is today (and, frankly, Micorosft is always changing direction before completing things).
• Today we have far better options such as Uno Platform which, aside from stability, didn't make the same mistakes as XF/Maui. The future is decided by decisions made today. The decision today is clear that there are better options than XF/Maui for cross-platform C#/XAML that are both more feature-complete and don't require developers to make arbitrary changes to naming and object model. You won't be able to compete with that especially with existing developers.
• You are right that being different isn't a bad thing. However, there were changes made just to be different and a lot of missing features from UWP/WPF. Whether that was done for legal reasons with Xamarin trying not to copy Microsoft is now irrelevant with Microsoft owning Xamarin.
• Don't forget UWP was poorly received when it was released because it made some unnecessary changes from WPF as well. Of course there are good improvements and developers accept change for the better (x:Bind, etc.) but the missing features were a big issue from the start with porting apps. Then UWP/WinUI has never been as stable as WPF was a few years after it was released. Now Microsoft is making similar mistakes again again with Maui; however, the stability is even less (from my perspective) and the changes are more far reaching than WPF->UWP. That's not a good place to be for future success.

from maui.

@dhindrik i think you mean on top of .NET Native (UWP) or .NET core 5. When you build a win32 winui app neither the wpf or win forms APIs are pulled in. You can’t even mix them right now (since XAML islands aren’t supported in the preview)

from maui.

@PureWeen
You can see the available keyboard shortcuts by pressing ? while not focused in an editor.

Submit comment and close issue
ctrlshiftenter

from maui.

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.

from maui.

I feel like there are a few things to unpack on the original post that don't really relate to XAML but the large focus of the comments have been about XAML so I'd like to touch on the non XAML things a bit first (sorry everyone :-p)

The readme definitely needs a bit more content
https://github.com/dotnet/maui/blob/build/README.md

But it has a general roadmap of what we are a planning and scenarios we are aiming to simplify. A lot of the direction will be influenced by these conversations!! So, it's really exciting reading everyones comments.

A few questions about your original post

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.

dotnet MAUI isn't just a rebranding. It's restructuring of the whole native layer and modernizing around net6 features and multi targeting. It's shedding as much legacy as we possibly can so that we can simplify and focus better. There's a huge focus on making switching to a native context much simpler. No more custom renderer attributes. Ideally you'd never have to create a custom renderer ever again.

Here's an issue talking about the new renderer structures and some linked videos
#28 (comment)

The architecture is non-ideal for custom controls as well.
Xamarin Forms is notoriously difficult to work with in an advanced way because of bugs and the complexity to fix them.

Can you expand on these statements with some examples? These are the scenarios we really want to simplify so I'm really curious to talk about the difficulties here

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.

Does this all have to be boxed together? If you felt really confident about the stability and if the feature set is there would you still not use dotnet MAUI because differences in naming?

@weitzhandler

lacks a lot of desktop I/O features and desktop-related APIs

What are some of the main APIs that are missing for you?

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.

Same question but now about Fluent :-)

from maui.

There were even some xamarin xaml standard controls in preview
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/xaml/standard
now they disappeared

from maui.

For example, where is the Control class? (Don't answer it, it's a rhethorical question :)).

Xamarin.Forms.View

from maui.

Xamarin.Forms.View is not remotely the same as WPF's Control. It doesn't support templating. It doesn't allow you to override input event handling behavior.

The hierarchy is the same, and the features missing is exactly the point of this discussion around MAUI.

from maui.

I'm not sure which side you're advocating for

I don't have a strong opinion on whether to use Xamarin.Forms hierarchy or WPF/UWP hierarchy. I just respond to comments made on this thread.

There is nothing in XF currently analogous to Control because XF relies on native rendering for visual and input behavior.

Here is a 1:1 correspondence table if we follow the object hierarchy (not considering features). Some of the correspondences are consistent.

TextBox/Entry:

Grid:

ListView:

from maui.

@legistek I appreciate it, thank you.

I wrote it like this, because in WPF, UIElement doesn't have Width/Height, it's on FrameworkElement. That's why I mapped VisualElement to FrameworkElement, because both have Width/Height properties (yes, we know, actually just one, the other one WidthRequest/HeightRequest etc). But from the class hierarchy I agree, VisualElement is more like UIElement like you mentioned, but with the option to define Width/Height.

But no matter what is right or wrong, this point shows exactly that the object models are different and you can't map the classes 1 to 1. It needs a lot of thoughts to align this.

There are a lot of other differences. For example, also the DataContext is in WPF on FrameworkElement. In Xamarin.Forms the BindingContext is on BindableObject, which is way more up in the class hierarchy.

from maui.

It needs a lot of thoughts to align this.

So we can decide whether to follow Xamarin.Forms or WPF and use the 1½ year gap until .NET 6 to implement the decision.

from maui.

MAUI Roadmap
@thomasclaudiushuber thanks for your kind reply. I would like to hear yours and the others opinion about Uno platform vs MAUI. Maybe Uno will be on top of MAUI in the future, but won't be in that case MAUI way behind it?

Uno Platform page states that it uses Windows-first XAML ‘dialect’, I don't know what does it mean in particular, but at least it sounds good.
I found there also, that it supports the following targets: UWP, WinUI 3 (even on Win7), Web (browsers, WebAssembly), Xamarin.Forms (Android, iOS, MacOS), WPF, porting of Silverlight projects.

Very important are also 3rd party (paid) UI controls. I posted a question to one of them about supporting MAUI and UNO. They have recently announced WinUI 3 preview components.

I'm particularly very interested in the Web targeting (sharing code with our desktop apps), using .NETSTANDARD libraries and C#/XAML.

Even Flutter has web support in development.

as @legistek wrote before me:

This all really does beg the question of why not to just use Uno.

from maui.

I would be happy IF there was some "conversion for making naming aliases" easy mechanizm. (or maybe just XAML alias extensions public github project owned by MS) than I could use it.

In fact you can't map 1:1 all XF controls to UWP/WPF/SILVERLIGHT but going opposite way should be possible.

I would go one step further with it and give developers easy way go with there own notations
as my pseudo HTML notation
https://medium.com/@boguslawblonski/enterprise-design-system-in-xamarin-form-28b7da49298c
Some transitions are not trivial
as https://www.w3schools.com/tags/tag_body.asp is not scroll view +stack layout

Why I would need all notations?

UWP/Silverlight

• I have big/complex/rich UWP (also same with windows phone) project would love to move it to XF/MAUI and do little refactoring where absolutely need (animations transitions..)
  Html
  -I have other ASP project that parts of UI (order process, list products ) + additional device work features.
  FX
  -well it have some controls that others don't.

Customers can afford only slite migration not full brand new project done from green ground.

Summing up:
Easy XAML aliasing mechanizm giving me freedom to switch between UI notations would work for me.

from maui.

Why not align MAUI object model to UWP, WPF, WinUI and build a single UI framework to rule them all? I don't care if it breaks compatibility with current XF (which I know and love) but if it's for the better of the .NET platform, I thing it's something that worth.

I think almost everyone on this thread shares that sentiment, but my point earlier was whether it's worth the effort of taking the legacy XF codebase and turning it into WPF or WinUI when there's something like Uno that's already done that.

I mean there are really so many different ways this could be approached. For example you could probably start with the WPF repo and adapt it to be cross platform, using the Xamarin backends for iOS and Android. You'd have to factor out Windows dependencies and recreate the native DLL that handles low level drawing and multimedia. You'd basically have Avalonia then but as a perfect WPF clone. Is that more or less effort than rewriting Xamarin Forms to use WPF syntax? I don't know.

from maui.

Why not align MAUI object model to UWP, WPF, WinUI and build a single UI framework to rule them all? I don't care if it breaks compatibility with current XF (which I know and love) but if it's for the better of the .NET platform, I thing it's something that worth.

Agree. Win UI 3 was announced and it is supposed to be a unification of UWP, WPF, WinForms. It should be a nice targeting platform for Windows

I am not wrong, WinUI is just a UI library on top of UWP, WPF and WinForms and not a unification of the platforms. It will still be different runtimes etc.

from maui.

I am not wrong, WinUI is just a UI library on top of UWP, WPF and WinForms and not a unification of the platforms. It will still be different runtimes etc.

Also admittedly a little confused, but I believe it's a library on top of the lower level WinRT/Win32 APIs. UWP, WPF, and WinForms can all consume it, and you also apparently will be able to make plain desktop apps with it directly without going through WPF or WinForms. To say it's unifying WPF and UWP though seems to be an overstatement/wishful thinking at best.

from maui.

but if we compare WPF/WINDOWS FORMS, Flutter seems difficult to use,

Indeed @fisforfaheem as stated a v1 tech. What will be interesting is seeing how //build 2021 and 2022 will look like and respond as Flutter continues to evolve, getting to v2 and v3 (and beyond?).

Btw, interesting data point here driving home the disconnect between management and actual developer usage/preference around Xaml:
https://twitter.com/jerrynixon/status/1265317553959624704

Get your votes in, 5 days left. 😁

from maui.

from maui.

I honestly want this to rival FLUTTER framework, But again, i can see from miles away that it cant rival that kind of thing, even .net 6 would be fragmented, whereas flutter is only going forward and would be ready in complete ALL platforms notion, they even support smartwatches and more things are coming soon. where as microsoft should combine WEB and APP development like flutter and make use of WINUI (windows FORMS) design and let us create apps in an easier and better way????
what do you say?

I'm for all about using WINUI, but please not Windows Forms. I think, at this point we have moved from drag and drop, and I feel that using that library would be a regression. Besides, if someone doesn't like XAML (too verbose, etc.), there is the fluent way using C# in a similar way how Dart is used in Flutter. If I'm not mistaken, the Xamarin Forms team even included in a recent version the library C# for markup, so there are now two ways to create UIs and I consider that "drag and drop" it's completely unnecessary.

from maui.

As well as adding what uwp/winui has that XF doesn't have.

What are these things?
Does it come down to wanting a NavigationView? A SplitView?

Xaml Features?

Other than StackPanel vs StackLayout what are you missing?

from maui.

How is XAML (the language) used with different frameworks any different from c# (the language) used with different frameworks?

Seems it's really easy to confuse XAML with the framework it's being used on. While it would be awesome if it was the same between all the frameworks, you aren't going to copy/paste a UWP or WPF UI XAML into forms and just have it work even if the XAML, controls, markup extensions aligned 100%.

Is this really an issue for developers or is it just a point of principle that they don't match?

from maui.

@dotMorten Thanks for the good explanation, I don't have to shift platforms much except back to Silverlight ever so often while I'm working on retiring it so it hasn't been that big of a deal for me.

It also makes sense how an abstraction layer over XF naming wouldn't work well. I was tossing around in my head how a separate package that could provide a shim from UWP controls -> XF might work and I can see how that could quickly spiral and be a maintenance nightmare! I'm all for unifying the object models, etc, as long as there is a good transition experience from XF to Maui.

from maui.

With only 12 months of support for XF v.Last promised after MAUI launch, is it really practical to leave a project on XF and not port it?

from maui.

with only 12 months of support for XF v.Last promised after MAUI launch,

Wait what?!?!?!? IMHO that's unacceptable. Do you have a link where it is saying that?

from maui.

https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/

Xamarin.Forms will ship a new major version later this year, and continue to ship minor and service releases every 6 weeks through .NET 6 GA in November 2021. The final release of Xamarin.Forms will be serviced for a year after shipping, and all modern work will shift to .NET MAUI.

from maui.