Please, stop Xaml

[am-kh]

Microsoft is going straight into the wall with Xaml. I've been a WPF developer for 15 years, but seriously stop the xaml, we don't want it anymore.
I don't understand this forcing from Microsoft.

[JohnHDev]

Its not forced, you can code your UI in C#.

[Xyncgas]

In fact I just stopped using XAML in MAUI and used blazor instead, and even with that I've stopped using the component declaration microsoft gave me, and I made my own rendering process that has renderer updating element when needed outputting to html.
Please stop Xaml

[nextcodelab]

In fact I just stopped using XAML in MAUI and used blazor instead, and even with that I've stopped using the component declaration microsoft gave me, and I made my own rendering process that has renderer updating element when needed outputting to html. Please stop Xaml

I worry of performance.. Maui in release mode still have delays in interacting the controls,, even animation is not fast.. menu clicking you can feel the delay..

[Xyncgas]

In fact I just stopped using XAML in MAUI and used blazor instead, and even with that I've stopped using the component declaration microsoft gave me, and I made my own rendering process that has renderer updating element when needed outputting to html. Please stop Xaml

I worry of performance.. Maui in release mode still have delays in interacting the controls,, even animation is not fast.. menu clicking you can fill the delay..

directly outputting to html is actually very fast, string operations are SIMD accelerated already

Without XAML, I could do things like pushing anonymous element (templated, for example I made a window on the spot without resorting to any specific control but you can open and close it and I get to set my broder color etc, like building a window with lego without first saying it's a window) to the RenderStack, dynamically changing or removing existing layout from the screen, computing all layout seperately in parallel, since all lambdas' capture are invisible to other lambda's capture generally

2023-02-08.22-57-46.mp4

[Xyncgas]

If I am using a browser instead of drawing UI directly using underlying UI framework like Avalonia does, I can still reach 144fps, CSS 'Animation' 'Trasition' Javascript 'RequestAnimatedFrame' are all GPU accelerated

[Xyncgas]

Just now as the window resized, so did elements, there was at least a couple frames generated by recomputing their new position and if it were lagging you would've seen the white background that's behind the dark background

[shadowfoxish]

Better than C++ .rc files. I'll take XAML over that any day :P

[marcvanbreemen]

we don't want it anymore

"We"? Talk about yourself.

XAML is a great way to create an UI. Much better than the code mess in for example Flutter.

[nextcodelab]

I think the reason flutter is fast, is that it draws controls on a whiteboard... they are not "real" controls like the ones Net Maui displays

I really like your reply it seems that is the reason why start up is just milliseconds,, I will upload my app created in flutter here,, we see the performance.,

[marcvanbreemen]

but the startup time and performance for third party platforms is very lag

XAML isn't interpreted in the final release build. XAML is translated to code and that code is compiled, just like when you code everything in C# instead of XAML.

XAML, Flutter or whatever layout technique doesn't make your app slow. It's often the programmer that is the cause of bad performing apps.

All my apps made with XF or MAUI are fast, as expected as they are eventually fully native (controls and app build). Flutter is always (a bit) slower (not always noticeable), because it doesn't use native controls, which are optimized by the OS.

[nextcodelab]

I think the reason flutter is fast, is that it draws controls on a whiteboard... they are not "real" controls like the ones Net Maui displays

This is the app I created maybe weeks or days... I really like the RiverPod because it will not affect on start up... this is a background task and when the data is ready it will replace the progressring widget with data viewer widgets....
Many Widgets here are from open sources projects.
THIS IS RELEASE MODE.

Untitled.mp4

HERE IS THE .NET MAUI APP IN RELEASE MODE. by https://github.com/rive-app/rive-sharp.

Untitled.mp4

[nextcodelab]

but the startup time and performance for third party platforms is very lag

XAML isn't interpreted in the final release build. XAML is translated to code and that code is compiled, just like when you code everything in C# instead of XAML.

XAML, Flutter or whatever layout technique doesn't make your app slow. It's often the programmer that is the cause of bad performing apps.

All my apps made with XF or MAUI are fast, as expected as they are eventually fully native (controls and app build). Flutter is always (a bit) slower (not always noticeable), because it doesn't use native controls, which are optimized by the OS.

As you can see my app created in flutter in release mode,,, no more delays... super fast in startup...
I will try this.
https://github.com/adospace/reactorui-maui

[Xyncgas]

The only thing you ever need with developing UI is event (gives interaction) and layout (position, dimension.. to draw it), no need for all kinds of elements, just like you can use 'div' in html for everything except of course sometimes you need img or svg

XAML basically gives you a bunch options for control, which is nice for people who doesn't do their own stuffs, but when you want to do your own stuffs you start to see them getting in your ways, and when you are creating new things it's very hard to move forward in XAML even if you are using minimum amount of contro : for example you would like to absolute position the element in xamarin and change it's position etc, you gotta write code behind and use binding where as in Avalonia / Flutter / Dart you drew the element in one line of code and you just need to tell the framework state has changed and modifies the value of the layout then it renders for you, everything is closer to you man, the fact that you have to go back and forth without staying in XAML entire to do what you want makes the process look elegant at first but lacks the freedom and piss people off when they are trying to be as liberal and creative as possible, if you stop using XAML and draw UI entirely in C# you can take advantage of its environment and change a layout of an element which was supposed to be read-only with pointer dark magic because your boss told you today it is required but tomorrow he changes his mind and see how much work you would've lost and how much fun you would've missed out by not playing with dangerous pointers.

Just let me say here is a spec of the elements, it can be produced by calling this function, and I can mutate the states captured by this lambda so the next time you ask me for the details, I give you something different to show on screen, because the spec is unchanged, but the detail has become different.

Please, stop Xaml

Allowing people to paint in C# opens the door for others languages people are comfortable in, even though Xamarin is cross platform and Xaml is describing the UI, you can't utilize this description and there is no helper library for serializing / deserializing Xaml for you to work at in .NET. Since Xaml is not to a text exchange format but a design language that will be compiled into binary anyways, we should not be using only Xaml but other languages that can be compiled too to achieve the same thing

In creative scenario, you build stuffs with stuff built, how are you going to put x left to y below d inside w then for each name in the setting enum replicate this layout down ward with text filled inside it with a specific font size and it holds true if y or d ever changed, in xaml lang one line? in F# you can simply curry functions

[williambuchanan2]

Have to admit I used to hate Xaml in the early days of WPF, but now that I am getting used to Maui I actually quite like it. Despite all the problems with Maui and Xaml I think it's quite good now.

Visual Studio could do with being a bit more helpful when using Xaml though - that's my main issue with it. It kind of feels like the people developing VS and the people developing Xaml are fighting against each other.

[idexus]

Similarly, I don't understand why Microsoft is still moving towards XAML. For simple applications it may seem ok, but when you want to do something more custom, things start to get tricky. For many of us, what we need is a solution that allows us to easily create an interface directly in the code, without the need to use XAML, but with similar capabilities. For this purpose, I opened a Pull Request, which opens the way to creating a user interface in a declarative way directly in the code. For those interested, please support me in this topic, and interest in this PR. I based my proposal on a library I created, which is a wrapper on the MAUI library. It uses the fluent API, in which you can clearly describe the interface directly in the code. I even managed to create a plugin for Visual Studio thanks to which Hot Reload for ContentPages created in the MVVM pattern is possible, which is very useful in many cases.

PR: #12728

[nextcodelab]

In XAML such a solution is rather not possible, in the code it is. Example from my lib:

you get this:

I like this,, but I think this is a .NET MAUI Grid in XAML and is slow or lag, maybe the controls will be stripped to different purpose, Like Row, Column, Spacing, Stack, Panel. one control for single task.

[idexus]

@nextcodelab I agree, it can be done differently. I mainly wanted to show that things can be written in code and it is much more readable than XAML and using the code for creating a UI, a man is no longer limited. People at Microsoft should understand that an out-of-the-box solution is needed for all those who are far from XAML that ties people's hands.

[Xyncgas]

Likewise in F#

margin, onclick, centering text is missing, but the spec for UI is only 2 lines really

Imagine having layout algorithm by your side, total control of z-index or when they appear and disappear, creating custom template in one line in code specifying background color font size etc, grouping elements together using type system, creating or disposing them together, and multiple ways to do this via recapturing of the elements to merge 5 render unit into 1 via operator overloading for example, fine grain sections of UI, move them out anytime and it would still work, static by default declaration in F# and lambda captures these static variable and create new instances that lives only inside them, therefore every render unit can be parallel computed and you can put 0 or 999 elements in them and they can be generated via algorithms for one or for a certain grid dimension. You feel at home, you feel spoiled, you feel like you never want to leave this place which you don't have to (no Xaml, no code behind)

I don't represent everyone, here I say I am happy if microsoft focus on giving me something I can output my description of UI to, the performance of converting your description to pixel should be super high. No bloated controls just one that allows me to attach event to and maybe special ones for img etc perhaps.

I will write my own algorithms, I will pick which element/control type I would like to use in my UI description, and I will be happy if I can absolute position things with z-index based on the order. But I can always write my own stuff in C++, to put pixels on the screen I guess. There is no way microsoft wants to work so close to me and get exactly how I want to draw how I want to write it's creative it's spiritual it's sacred

[LuohuaRain]

@Xyncgas is this Fabulous Framework?

[Xyncgas]

@LuohuaRain it's a framework I created

[davepruitt]

I'm a big fan of XAML. It creates a nice clean separation between UI and code. I've been using XAML for about 15 years now with WPF, Silverlight, Xamarin, and MAUI, and I say keep using XAML.

[nextcodelab]

I'm a big fan of XAML. It creates a nice clean separation between UI and code. I've been using XAML for about 15 years now with WPF, Silverlight, Xamarin, and MAUI, and I say keep using XAML.

I like the XAML but,,, XAML is lag than direct draw on code,, I tried it with ScrollView => Stackpanel => 100x TextBlock Children with long text each, my screen hangs and lags.

But in flutter you add app to 1000x Text() with hundreds of Widgets in ScrollView and it doesn't slow down or lag the scrolling (PLUS ALL STYLING IS AVAILABLE).

[idexus]

@nextcodelab You can achieve it, but you can't use StackLayout and ScrollView for it.

Suppose you have 10,000 items to display

public class MyData
{
    public int Id { get; set; }
    public string Text { get; set; }

    public static IEnumerable<MyData> Source = Enumerable.Range(1, 10000).Select(id => new MyData
    {
        Id = id,
        Text = $"Lorem ipsum dolor sit amet. Sit quos odit et reiciendis delectus et " +
        $"ullam quis aut Quis quia! In sequi quasi quo asperiores repellat a totam " +
        $"quod sit odio quaerat et odit molestiae et magni perferendis rem accusantium " +
        $"asperiores. In exercitationem totam qui consectetur quae et cupiditate suscipit " +
        $"qui labore illum ut autem dolorem.Ut rerum harum non voluptatem officiis qui " +
        $"voluptas nulla ut nulla explicabo ut itaque quaerat quo corrupti nulla cum " +
        $"blanditiis reiciendis. Et ratione voluptate et autem fugit ad ratione ipsam " +
        $"aut dolor nihil. Vel nihil tempore et consectetur saepe et quia internos qui " +
        $"minima dolorem. Aut nemo commodi ut maiores autem ab magni nihil ut nemo " +
        $"exercitationem. A error deserunt in culpa veniam ut beatae provident aut animi " +
        $"reiciendis non similique dolores sed omnis quae in dolorum enim. Et velit dolore " +
        $"ea dolores nihil ut rerum voluptatem sit deserunt asperiores aut libero quisquam."
    });
}

When you put it all into Stack, you get, nothing more, a very laggy application.

new ScrollView
{
    new VStack
    {
        MyData.Source.Select(data => new VStack
        {
            new Label()
                .Text(e => e.Path("Id").Source(data))
                .FontSize(30)
                .TextColor(Colors.Blue),

            new Label()
                .FontSize(20)
                .Text(e => e.Path("Text").Source(data))
                .HeightRequest(200),
        })
    }
};

This is because the StackLayout implementation doesn't allow you to reuse components here, instead it throws everything into itself, these 10000 elements.

The situation is different in the case of CollectionView. Here, several views are created, and rotation between them takes place during scrolling. And it's not about whether it's an MVVM or MVU pattern, whether you're using XAML or not. It's about how it's implemented inside the MAUI library.

new CollectionView(e => e.ItemsSource(MyData.Source))
{
    () => new VStack
    {
        new Label()
            .Text(e => e.Path("Id"))
            .FontSize(30)
            .TextColor(Colors.Blue),

        new Label()
            .FontSize(20)
            .Text(e => e.Path("Text"))
            .HeightRequest(200),
    }                
};

I think a big change is needed. Of course, you can try to use CollectionView for this, but what I mean here is rather a change of philosophy, where the necessary content is created in elements such as Grid or StackLayout on demand, when there is a need to display it, and reusable views, disappearing from the screen, could be reused by another piece of code.

[nextcodelab]

@nextcodelab You can achieve it, but you can't use StackLayout and ScrollView for it.

Suppose you have 10,000 items to display

public class MyData
{
    public int Id { get; set; }
    public string Text { get; set; }

    public static IEnumerable<MyData> Source = Enumerable.Range(1, 10000).Select(id => new MyData
    {
        Id = id,
        Text = $"Lorem ipsum dolor sit amet. Sit quos odit et reiciendis delectus et " +
        $"ullam quis aut Quis quia! In sequi quasi quo asperiores repellat a totam " +
        $"quod sit odio quaerat et odit molestiae et magni perferendis rem accusantium " +
        $"asperiores. In exercitationem totam qui consectetur quae et cupiditate suscipit " +
        $"qui labore illum ut autem dolorem.Ut rerum harum non voluptatem officiis qui " +
        $"voluptas nulla ut nulla explicabo ut itaque quaerat quo corrupti nulla cum " +
        $"blanditiis reiciendis. Et ratione voluptate et autem fugit ad ratione ipsam " +
        $"aut dolor nihil. Vel nihil tempore et consectetur saepe et quia internos qui " +
        $"minima dolorem. Aut nemo commodi ut maiores autem ab magni nihil ut nemo " +
        $"exercitationem. A error deserunt in culpa veniam ut beatae provident aut animi " +
        $"reiciendis non similique dolores sed omnis quae in dolorum enim. Et velit dolore " +
        $"ea dolores nihil ut rerum voluptatem sit deserunt asperiores aut libero quisquam."
    });
}

When you put it all into Stack, you get, nothing more, a very laggy application.

new ScrollView
{
    new VStack
    {
        MyData.Source.Select(data => new VStack
        {
            new Label()
                .Text(e => e.Path("Id").Source(data))
                .FontSize(30)
                .TextColor(Colors.Blue),

            new Label()
                .FontSize(20)
                .Text(e => e.Path("Text").Source(data))
                .HeightRequest(200),
        })
    }
};

This is because the StackLayout implementation doesn't allow you to reuse components here, instead it throws everything into itself, these 10000 elements.

The situation is different in the case of CollectionView. Here, several views are created, and rotation between them takes place during scrolling. And it's not about whether it's an MVVM or MVU pattern, whether you're using XAML or not. It's about how it's implemented inside the MAUI library.

new CollectionView(e => e.ItemsSource(MyData.Source))
{
    () => new VStack
    {
        new Label()
            .Text(e => e.Path("Id"))
            .FontSize(30)
            .TextColor(Colors.Blue),

        new Label()
            .FontSize(20)
            .Text(e => e.Path("Text"))
            .HeightRequest(200),
    }                
};

I think a big change is needed. Of course, you can try to use CollectionView for this, but what I mean here is rather a change of philosophy, where the necessary content is created in elements such as Grid or StackLayout on demand, when there is a need to display it, and reusable views, disappearing from the screen, could be reused by another piece of code.

Hi thanks for your code,, in xaml binding in collectionview , I will create sample app for .net maui base on this code,,,
and I will also create app in flutter with the same UI intension, and compile all on release mode... we will compare the two. THIS REPLY FOR WAITING THE RESULTS IN MAIN ANSWER.

[Xyncgas]

@idexus thanks

[janseris]

@davepruitt or even use LINQ to achieve the same result. The code gives you much more options. The description becomes more concise, less prone to mistakes.

new Grid(e => e
    .RowDefinitions(e => e.Auto(count: 5))
    .ColumnDefinitions(e => e.Absolute(80, count: 3))
    .HorizontalOptions(LayoutOptions.Center)
    .VerticalOptions(LayoutOptions.Center))
{
    ...

    new Button("\x21E6").Command(vm.DeleteCharCommand).Column(2),

    labels.Select((label, i) =>
        new Button(label)
            .Row(i/3+1).Column(i%3)
            .Command(vm.AddCharCommand).CommandParameter(label))
};

Except that it cannot be compiled?

[Ghostbird]

We've mostly phased out XAML for our app too. We're using MAUI CommunityToolkit.Markup. It keeps the UI‌ definitions very readable, and avoids all the pitfalls of XAML. For us the choice was easy, since we're loading rather dynamic UI. Using XAML was not a good option. If you're making something very static, XAML might give better performance.

[gdamino]

MAUI with XAML is not suitable to large app and in my opinion is not even ready to small app.
Write an easy page is XAML is a pain, binding data to it is not intuitive and last but not least the result is an app very very very very slow.
It takes seconds to change from a page to another page even on powerful hardware.
We completely abandoned XAML and we wrote a framework from scratch that allows us to write a well formed complex page in little time.
And very importantly it is extremely fast, almost 500 times faster than MAUI+XAML, page navigation is instantaneous.
On top of this, we are immune to the thousands of bugs that plague MAUI controls, which has taken a big burden off our shoulders.

[janseris]

XAML is not intuitive because it's powerful. If you want intuitive UI you can use Winforms
what is that framework of yours? Can you show us so the MAUI team can learn how to make it 500 times faster?
There is a large plague of bugs indeed in MAUI (I am not siding with the team).

[tjiakwokyung28]

Microsoft is still moving towards XAML, so that we can make our own tools according to our needs, different from the fluter provided by Google, developers prepare it and just use it but can't make it themselves

[RobTF]

I theorize that part of the reasoning for things like XAML is that the idea was it could be compiled at runtime for fast execution but was friendly enough for WYSIWYG tooling to parse at design time too to give a good development experience. It would generally be much more difficult for an editor to pluck some random class out of your code and execute the UI bits in isolation to create a preview.

This is why in WPF it made perfect sense; you write XAML and the tooling created a nice representation of your UI. You compile your app and the XAML is compiled into IL and for the most part disappears. The XAML acted as a way of describing the UI separately to the app logic.

That said, for MAUI there is no design-time tooling so that advantage is pretty much zero. So I'd see using XAML vs C# as 50/50 except in my experience the hot reload for C# is far flakier than the XAML hot reload for non-trivial apps.

[saint4eva]

xaml should be discontinued. All other modern platforms for apps development are using code for their UIs and business logic.

[williambuchanan2]

@saint4eva why? What is the reason for discontinuing xaml?

[williambuchanan2]

I don't really get the negative comments about XAML. I find it quite nice to use. I see people commenting that it's not modern and not up to the job, but without really providing any reason for those comments. From what I can see it works fine and is easy to use.

What are the alternatives, and what benefit do these alternatives bring? What can you do with these alternatives that you can't with XAML?

[davepruitt]

Yeah, I don't really fully understand the negative comments about XAML either. I find it to be a nice way to describe a UI, and to separate the UI description from code. I think XAML is much much much better and more intuitive than HTML/CSS.

While there are some cases in which the UI needs to be done in code, I think XAML is excellent as a way to define/describe a UI for the majority of use-cases.

[TedMobile]

I have written in both xaml and mark up and I personally prefer xaml .yes it’s verbose but if you know what you are doing u keep it simple. Also if want to see at glance what a page is doing I find it a way better with xaml . Lastly more importantly no one is forcing you to use it and may be you should concentrate the effort in raising issues to have bugs fixed. Given a choice xaml all the way

[CodingOctocat]

I prefer xaml, xaml should not be abandoned，The xaml syntax and intellisense should be enhanced.

[williambuchanan2]

I agree - it's hard to understand how after 17 years of XAML the intellisense still barely works. If they fixed that it would make it much easier for newbies to learn.

[am-kh]

XAML is a dead technology. No young developer today is going to invest the time to learn it. It feels heavy and outdated. We see modern frameworks like Flutter, SwiftUI, or even JavaScript-based solutions that only require a single language to create beautiful, high-performance apps. C# alone could be enough to achieve great results, just like those frameworks do with a single language.

I also wonder if Microsoft even fully supports XAML anymore, or if it's just a legacy from Xamarin. It doesn't seem like an intentional choice for the future of app development.

[RobTF]

I think how the UI is declared is one of the least important parts.

In my opinion XAML is fine, maybe a tad verbose in places (some of the binding syntax, data triggers etc.) but ultimately it's pretty simple to work with.

XAML can't have any impact on runtime performance except regarding debugging overhead for hot-reload as it is compiled into IL at build time and runs like any other code. You might argue that the C#/IL generated is ill-performing but looking at what it does it looks very simple, just object instantiation so I doubt there's anything of substance there, so the "high performance" aspect of the alternatives is not really a point.

Is it better or worse than using C# to describe a UI? I'd say not, again I'd point to tooling being a potential benefit if not the number 1 reason for a markup language should those tools exist. The markup language allows tooling to narrow its focus on the domain in scope (in this case UI) and the markup language sets the restrictions allowing such tools to exist. Straight code has no restrictions which causes problems for tooling, and sometimes you can start to see aberrations where restrictions are bolted on such as the horrible stuff around the Hooks concept that React uses where there are a non-trivial number of rules a developer must remember to follow or risk creating very subtle bugs.

There used to be a rich ecosystem of XAML editing tools, such as Expression Blend, Expression Design and others as well as brilliant support for XAML based WPF apps in Visual Studio - I'm sure this still exists but I haven't done WPF in a long time. It's a shame these are gone and maybe @am-kh has a point about Microsoft not really supporting it properly.

For technical reasons MAUI is pretty much devoid of such tools and relies heavily on hot reload as a crutch, turning the app being developed into its own design previewer, but this has lots of problems. For example there is an overhead to enabling hot reload which slows the app down considerably and the way changes are applied is inconsistent. By inconsistent I mean that in MAUI many components are sensitive to the order in which properties are set and changes applied from hot reload do not take this into account giving inconsistent results.

Those problems however are due to how MAUI works, and are not especially related to XAML.

TLDR; Keep XAML!!!

[janseris]

XAML can't have any impact on runtime performance

That's a hillarious statement. MVVM is decoupled using reflection.

[RobTF]

XAML can't have any impact on runtime performance

That's a hillarious statement. MVVM is decoupled using reflection.

Sorry I don't follow, do you mean via bindings? Couldn't C# code use bindings too? One could implement MVVM without XAML couldn't they? Likewise you could use XAML and forego MVVM couldn't you?

If you do mean bindings I believe they are trying to eliminate reflection with compiled bindings which works with both C# code and XAML.

[janseris]

From what I read at that link it seems they are compile-time checked bindings and it does not change runtime performance.

[RobTF]

The binding resolution is compile time. Compiled bindings eliminates the need for reflection and directly impacts runtime performance.

It is also aside of anything to do with XAML.

[tjiakwokyung28]

stop your xaml project dont use maui, using fluter, you dont find xaml again

[RobTF]

Flutter is interesting and is often cited as the "MAUI alternative" but isn't this just a UI framework for native apps?

Our team doesn't want to mess around with XCode and Android Studio, with two codebases, port shared code from C# to Swift or Kotlin etc. MAUI brings more than this to the table.

Perhaps what would be interesting would be a fully supported <Flutter /> component which renders flutter UI into a MAUI app with some decent interop layer.

[tjiakwokyung28]

Flutter, SwiftUI, or even JavaScript-based cannot create extraordinary project like net maui, because flutter, swiftui or even javascript run inside mini browser which is specially made for mobile app

[RobTF]

@tjiakwokyung28 To be fair I think Flutter renders using Skia, not a web browser view, more akin to how a video game would render its custom UI.

You might be thinking of Electron which I believe does this.

[williambuchanan2]

Flutter, SwiftUI, or even JavaScript-based cannot create extraordinary project like net maui, because flutter, swiftui or even javascript run inside mini browser which is specially made for mobile app

Those sound more like negatives than positives. Again, no actual reason given for why we should avoid xaml...

[idexus]

It seems to me that the problem is not about discontinuing XAML in MAUI through a top-down decision, but rather about providing a good alternative for those who find building applications directly in C# code a better and more flexible solution. I believe the issue will resolve itself, as people will make their own choices, rather than a group of managers with a preference for HTML, CSS, and XAML. Yes, these are technologies that have allowed content to be described over the years, but unfortunately, they are very limited, not type-safe, and difficult to debug. Not to mention the significant unreadability of such "code", which is hard to even call code—it's more of a view description. All of this can be achieved using C# and fluent methods, thus benefiting from the richness of a mature programming language like C#. Of course, there is the CommunityToolkit/Maui.Markup, but it's not part of Microsoft, rather a community-driven approach, which means it's not an out-of-the-box solution, and many methods remain unresolved. Over a year ago, I created a library as a proof of concept (Sharp.UI) using code generators to show a different approach—that it can indeed be done—and based on it, I even built several production projects without a single line of XAML. So, as they say, it is possible to do it differently.

[RobTF]

I agree, choice is good.

[saint4eva]

Maui ReactorUI ❤️

https://adospace.gitbook.io/mauireactor

[williambuchanan2]

but unfortunately, they are very limited, not type-safe, and difficult to debug. Not to mention the significant unreadability of such "code", which is hard to even call code—it's more of a view description.

It looks like the reasons you give are:

• Xaml is very limited
• Not type safe
• Difficult to debug
• Unreadable

I wouldn't say Xaml is very limited. If you want to build a business app or a data app (which probably covers 70% of apps) it gives you everything you need. You can build these apps using Xaml incredibly quickly.
Not type safe - agreed this can be annoying but not a show stopper, and the same can be said for many languages.
Difficult to debug - maybe a little on the odd occasion.
Unreadable - I disagree.

So still, from my point of view, I don't see what is so bad about Xaml that is supposedly so much better using others...

[idexus]

Unfortunately, XAML can hardly be called a programming language, at best a standardized data description language, and in the case of views in MAUI, merely a description of the structure of objects on the screen. Of course, there are people for whom this is sufficient, but what I’m saying is that there should be an alternative for those who think differently. As for the readability of the “code”, I don’t personally know anyone who shares your view. For me personally, it’s not readable, but I respect your opinion.

Choice is good, and it would be great if it came out-of-the-box.

[am-kh]

Here’s why:

1. XAML is heavy and verbose: Compared to C#, XAML requires a significant amount of code to perform simple tasks. Features like converters, DataTemplateSelectors, and triggers demand large blocks of XAML, whereas in C#, these tasks can be done in just a few lines. This verbosity makes XAML less attractive, especially for newer developers who prefer more modern and concise solutions.

2. Lack of evolution: XAML hasn’t evolved meaningfully in years. WPF, which relies on XAML, has also stagnated, and Silverlight, another XAML-based technology, was discontinued by Microsoft due to poor adoption. MAUI with XAML appears to be heading in the same direction, with little momentum for growth.

3. Adoption issues: MAUI with XAML has struggled to gain traction. As of now, I haven’t seen any major products developed by Microsoft using MAUI, which raises questions about its viability. If this technology were truly promising, Microsoft would have showcased it with a high-profile project by now.

4. Personal experience: I recently worked on a greenfield project with MAUI, and it was a total failure. We encountered numerous bugs and severe performance issues, particularly with CollectionView, which many developers have also reported. This shows that MAUI, in its current form, isn’t ready for serious projects.

5. MAUI.iOS, a better alternative: On the other hand, MAUI.iOS, which is purely based on C#, avoids these problems, making development much smoother and more enjoyable. Developers who claim XAML is great have likely never tried Flutter or even MAUI.iOS. I invite them to do so, and I’m confident they’ll change their minds quickly.

6. Other significant drawbacks of XAML:

   • Lack of debugging: XAML doesn’t provide a robust debugging experience, making it difficult to track down issues during development. This is a major pain point when compared to the ease of debugging in C#.
   • Relies heavily on reflection: XAML-based solutions often rely on reflection, which adds runtime overhead and complicates performance optimization, especially on mobile platforms where resources are limited.
   • Weakly typed: XAML is not strongly typed, which leads to errors that only appear at runtime rather than compile time. This makes code harder to maintain and more prone to bugs, whereas C# offers the advantages of compile-time type checking.
   • Tooling limitations: The tooling for XAML is still lacking in many areas, especially when it comes to design-time support and integration with modern IDEs. This creates friction in the development workflow.
   • Performance concerns: XAML-based UIs are often slower and less responsive compared to C#-driven frameworks. The runtime parsing of XAML adds overhead, and the rendering performance lags behind more modern UI frameworks like Flutter.

To give some context, I’m a developer with 10 years of experience in WPF, Silverlight, and Xamarin, and I’ve also worked with Flutter. I can assure you that any company starting a mobile app project without technical constraints tied to the .NET ecosystem would never choose MAUI. Tools like Flutter are far superior, more performant, and better suited to current development needs.

[RobTF]

Maui ReactorUI

https://adospace.gitbook.io/mauireactor

Looks nice - I haven't looked in detail but how is the dev loop/hot reload experience?

[RobTF]

1. Xaml is heavy and verbose:

<Button Text="Click Me" />

Is that more verbose than any other?

To be fair, if you're using string resources and want the button to actually do something it's probably more like;

<Button Text="{x:StringResource ClickMe}" Command="{Binding ContinueCommand}" />

I'm still pro having the XAML option though - personally I like it! I think you're right though and people are conflating MAUI issues with XAML issues. XAML "issues" can only be in the runtime (which I think is fine as per my post above) and the tooling (which is OK but needs work for better intellisense etc).

[am-kh]

1. Xaml is heavy and verbose:

<Button Text="Click Me" />

Is that more verbose than any other?

2. Lack of evolution: What are you comparing it to? Just because it hasn't changed much doesn't mean it doesn't work well. What is it lacking by not evolving?

3. Adoption issues: It's literally been the main UI for all Microsoft dev for 17 years, and is now in Maui which is the latest Microsoft product.

4. Personal experience: from what you say it looks like you ran into Maui bugs - this is nothing to do with Xaml. Try writing the same UI in C# and you will see the same bug.

5. Maui.iOS a better alternative: The only benefit you say is that it is smoother - I don't see that. The end result is the same.

6 Other significant drawbacks: yes you have some valid points here, but I would say these are minor irritations.

I agree with your points on Maui - I have been complaining like crazy on here about how bug ridden and borderline unusable it is, but this thread is about Xaml - not Maui. Many of the things you note above seem to be more Maui related than Xaml.

1. XAML is heavy and verbose:
Your example of a simple button <Button Text="Click Me" /> is not really representative of what makes XAML verbose. Sure, a basic button declaration might not seem heavy, but once you start adding things like converters, DataTemplateSelectors, Triggers, and other more complex features, XAML quickly becomes verbose and cumbersome to maintain. If you want to challenge the verbosity claim, it would be more appropriate to show how you handle those more complex scenarios in XAML. In C#, those same tasks can often be done more concisely and clearly, without needing to rely on lengthy XAML declarations.

2. Lack of evolution:
The fact that XAML hasn’t changed much over the years is exactly the problem. While it might "work," it has stagnated in terms of features and developer productivity compared to modern UI frameworks like Flutter. What is it lacking? The flexibility and developer efficiency that you get from a more modern language-based UI design. With C#, you can use better tooling, refactoring, debugging, and more powerful type checking. XAML, on the other hand, still has the same old design-time issues and limitations, which slow down development.

3. Adoption issues:
Yes, XAML has been around for 17 years, but its adoption has been mostly tied to Microsoft’s internal ecosystem. Outside of that, it hasn’t really gained much traction. And the reason why XAML is in MAUI is not because developers love it but because it was inherited from Xamarin.Forms, which also relied on XAML. This wasn’t a fresh choice by Microsoft, but more of a migration path with a few improvements. Unfortunately, this legacy has also carried over many of the issues we see today in MAUI.

4. Personal experience:
You're correct that the bugs I encountered are related to MAUI, but XAML plays a role here as well. XAML is tightly coupled with how the UI is structured in MAUI, and it adds its own layer of complexity and limitations on top of the bugs we encounter. Writing the same UI in C# often results in clearer code and fewer issues around reflection, weak typing, and debugging. XAML amplifies the pain of dealing with those bugs because it lacks strong developer tools for troubleshooting and optimizations.

5. MAUI.iOS a better alternative:
The smoother experience with MAUI.iOS isn’t just a subjective feeling. When you stick to C# without having to deal with XAML's verbosity and limitations, the development process becomes more fluid. The end result might look the same, but the development experience is vastly improved when you don’t have to fight XAML's quirks. It's more about developer productivity and long-term maintainability, which is better with C#.

6. Other significant drawbacks:
I appreciate that you agree with some of the points here, but I wouldn’t call them "minor irritations." For developers, things like lack of debugging support, reliance on reflection, and weak typing are major pain points. These issues directly impact developer productivity, code quality, and performance. And if MAUI, which is built on XAML, fails to address these problems, it is destined to struggle in adoption.

In the end, XAML's complexities are part of the reason why MAUI is facing so many challenges. If Microsoft had taken a different approach, focusing entirely on C# and creating a modern, powerful framework like Flutter, we might not be having these same discussions. Unfortunately, they stuck with XAML as part of their Xamarin.Forms migration, which carried over many of the same issues instead of starting fresh with a more developer-friendly solution.

[williambuchanan2]

I guess we have to agree to disagree. I am very comfortable with Xaml and I don't see the issues you raise as being of much significance. I guess we all get comfortable with what we learn to use, and on that point I should probably learn Flutter so that I can see what i'm missing!

[saint4eva]

Maui ReactorUI
https://adospace.gitbook.io/mauireactor

Looks nice - I haven't looked in detail but how is the dev loop/hot reload experience?

It is really amazing. Better hotreload and better tooling because you are just writing amazing C# both front and back - it gives you better end-to-end development experience.

[gdamino]

In you have to build a big app, XAML, today, is not the way. I'm not speaking from hearsay, we lost 6 months of development trying to do things with XAML. So we developed our own framework, now a page can be written in a short time, zero bugs, no crazy bindings, loading speed 500 times faster than MAUI+XAML. The framework supports navigation (done well), dialogs, all the controls found in MAUI plus a few dozen more, and it also works in Blazor, WPF, WinForm and more.
Maybe a day we will
I'll show you an example of how to build a page:

The page:

The code:
`
///

/// This class is designed to be a page and it's based on PGrid class.
/// every object are equals, pages or buttons are the same you can navigate to every object or put every object inside another one.
///

///
public class PageDemo(ViewData viewData) : PGrid(viewData)
{
private readonly Style[] _styles = [
Plasma.TitleMini,
Plasma.DescMiniCentered,
Plasma.Monospace2,
Plasma.Regular.Modify(blurred: true).AbsoluteCentered()];

private readonly string[] someData =
[
    "Title mini style",
    "Desc mini centered style",
    "Monospace",
    "Regular Style blurred",
];

private (DateTime date, double value)[]? _randomdata;

protected override void OnFirstRender()
{
    Title.Text = "This is a demo page";

    InitRandomData();

    base.OnFirstRender();
}

protected override void OnDisposing()
{
    //clean resources etc..
    base.OnDisposing();
}

public override void Draw()
{
    Clear();

    PinDescMiniGray(
        "Some multiline long text\nSome multiline long text,\nfollowed by a 3x2 table:",
        1);

    //A table is a container organized in rows and columns capable of holding any type of framework object
    PinRow(CreateNewTable(), 3);

    PinRow(null);

    PinOptionRow(
        "Setting",
        "this is a very important call-to-action object and in this case it will show a dialog",
        null,
        () => ShowDialog("hello"),
        "@SETTINGS",
        Plasma.Accent1);

    //Then we will show a graph with some random data
    var graphInfo = new GraphInfo("Some random data", _randomdata ?? []);
    var graph = new PGraph(ViewData, graphInfo);
    PinRow(graph, 4);

    PinImageButton("@PLUS", "Add something", IncrementAction);

    //A toolbar, back button will navigate back to previuos page,
    //next button will navigate to a new page
    DrawToolbar();

    base.Draw(args, rect);
}
private void DrawToolbar()
{
    var toolbar = new PToolBar(ViewData);
    toolbar.AddToolbarButton(
        "@BACK",
        "Back",
        ViewData.GoBackAction,
        PlasmaAlign.Start,
        2,
        Plasma.LightStrong);

    toolbar.AddToolbarButton(
        "@UP",
        "Navigate to new page",
        () => ViewData.Navigate(new PageDemoSecond(ViewData)),
        PlasmaAlign.End,
        2,
        Plasma.Accent3);

    toolbar.AddToolbarButton(
        "@SAVE",
        "Save",
        () => ViewData.Navigate(new PageDemoSecond(ViewData)),
        PlasmaAlign.End,
        2,
        Plasma.Accent2);

    PinRow(toolbar);
}

private PTable CreateNewTable()
{
    var table = new PTable(ViewData, 3, 2, borderColor: Plasma.Black, backgroundColor: Plasma.Light);

    for (Int32 i = 0; i < someData.Length < _styles.Lenght ? someData.Length : _styles.Lenght; i++)
    {
        table.AddSubItemLabel(someData[i], _styles[i]);
    }

    table.AddSubItemButton($"Button {_counter}", IncrementAction);

    table.AddSubItemImageButton(
        "@GARDEN",
        $"ImageButton",
        () => IncrementWithArgsAction(2),
        Plasma.Accent2T);

    return table;
}

private void ShowDialog(string text) => ViewData.ShowDialog("title", text);

private void InitRandomData()
{
    var rand = new Random();
    var list = new List<(DateTime date, double val)>();

    for (var i = DateTime.Today; i < DateTime.Today.AddDays(1); i = i.AddHours(1))
    {
        list.Add(new(i, rand.NextDouble() * 100.0));
    }

    _randomdata = [.. list];
}

private int _counter = 0;
private void IncrementAction()
{
    _counter++;
}

private void IncrementWithArgsAction(int dummy_arg)
{
    _counter += dummy_arg;
}

}
`

Maybe one day we will publish it opensource and/or monetize, or we will sell it to Microsoft so they can provide an alternative to XAML, who knows.

it supports horizontal view ratio and auto text size adapting:

[davepruitt]

lol. I could design this page in XAML in a matter of minutes. I was expecting more.

[gdamino]

For sure you can. But the goal is not design an empty demo page but an entire complex production app.

[RobTF]

To be honest that UI looks a bit wonky. Spacing is off such as the Setting option and it's sub-text and the icons of buttons look oddly aligned maybe missing some left padding. It feels homebrew.

I cant quite put my finger on it but it has the feel of an Adobe Flash website from the 2000's and doesnt feel like a native app to me but that might just be the font/stylistic choice as opposed to a fundamental problem with what you're doing.

Rendering widget looking graphics using an object model and something like Skia is relatively straightforward. The test of a "framework" would be how things like styling, multi language (e.g RTL text), text highlighting, clipboard support etc. work.

How do your components handle property changes? for example, if the graph was displaying live data? Is the whole thing created and drawn from scratch every frame or is it smarter than that?

Hand rolling a UI framework is a big undertaking. I know this from experience making a small game engine a while back, I'm not sure many businesses would be able to put time into such an endeavour as it doesn't directly deliver business value. I respect what you've done but it's definitely an edge case and not a palatable alternative to XAML for most users.

[williambuchanan2]

Don't mean to be rude, but again it seems this is confusing Maui bugs with Xaml. Also, compared to the code you have shown here I would say Xaml is much cleaner and easier to read, and I think that mixing UI code in with other code is going back to how it used to be done 20 years ago.

So i'm still not seeing what the big problem is with Xaml.

[jpgarza93]

Agree, this page in xaml would take minutes. I have designed many complex apps in xaml. The key is to learn xaml first, then start using it. Pluralsight has many great courses

[gdamino]

Thanks for feedback, you are right about some things, for other things, however, I think differently.
About the appearance itself we known that it doesn't feel like a "native" experience (I think we need to hire a developer only to do this for reach that level), but for our use case it just good for our goal.
The point is that if you want to build the same app using XAML, you simply can't, even if you put a lot of effort into it. The first problem is performance, MAUI apps are not slow, natively compiled they are very fast, but if you use XAML everything becomes extremely slow (and you get tons of unsolvable MAUI bugs), and this is a problem because the result is an unusable app for the end user. And I know that XAML is just a markup language and the problem lies somewhere else, but this is the state of things. The other point concerns XAML itself, we do not find it fast to write a page or a control in XAML, experience makes me say this, as we had already written about 30 pages and as many controls before venturing to write a framework, it's a real headache.
Finally, I don't find "old" or "wrong" to put UI code together with other code, as long as this is clean. If you use partial classes in the end practically nothing changes.
For the property changes handling it redraw the entire page. There is an algorithm that caches changes. But still despite the page being completely redesigned the update is hundreds of times faster than MAUI+XAML and the use of the CPU is almost zero.

[davepruitt]

Sorry dude, but hard disagree.

I have built multiple MAUI apps that are currently being used as medical device software. We use XAML a ton, and I have never had any issues building any apps with XAML at all. These are apps that are very stringent with bugs due to being used with medical devices. So we do a lot of testing. And these are also not "simple apps" either.

I'm not saying MAUI doesn't have issues. But your claims of needing to develop your own entire UI framework because "XAML just ain't cutting it" are completely unfounded.

If it's just a matter of preference - you like defining your UI in code - that's one thing. But XAML ain't all super buggy and useless as you try to say it is.

[RobTF]

The point is that if you want to build the same app using XAML, you simply can't,

Unless I'm missing something about that example, that is just incorrect. We've built far more (what I would consider) complex UI layouts on my team using XAML. What specifically do you think you could not express using XAML or the C# declared UI MAUI offers out of the box?

[developer9969]

Please close this issue - is just a waste of time- Maui Team can hardly cope with bugs let alone this useless discussion. Code as you wish - c# - xaml - etc.. and concentrate efforts in discussion that help fix real issues.

[idexus]

Look - I have been in this business for 20 odd years and I have seen how software as evolved and how big companies have changed their tune. From a realistic prospective you are just wasting your time in this thread and is just noise really , they can hardly fix what is important -- I.E keyboard issues - LayoutIssues - Memory leaks etc. last thing is the "stop xaml" .

I Have done both xaml and c# for markup, and I prefer xaml , but that is my choice , noone stops you using c#, and microsoft is not imposing either.,.. You have a choice I dont see the problem.

I have been in the industry for over 30 years, and I can also see how everything has evolved, and I’m not necessarily happy about it, which is why I’m contributing to this discussion. In my opinion, if everyone just follows the crowd, nothing will change. We can’t blindly accept what is being served to us. We have increasing computational power, yet unfortunately, applications are not exactly known for their speed — something is causing this. We focus on the speed of application development, while performance is often placed second. I won’t even mention optimization and code quality... :(

[RobTF]

Look - I have been in this business for 20 odd years and I have seen how software as evolved and how big companies have changed their tune. From a realistic prospective you are just wasting your time in this thread and is just noise really , they can hardly fix what is important -- I.E keyboard issues - LayoutIssues - Memory leaks etc. last thing is the "stop xaml"...

I have been in the industry for over 30 years, and I can also see how everything has evolved, and I’m not necessarily happy about it, which is why I’m contributing to this discussion. In my opinion, if everyone just follows the crowd, nothing will change. We can’t blindly accept what is being served to us....

I've been in the business 40 years before XAML even had an X and people were making do with just the A, M and L. You're all just spoilt.

[davepruitt]

I've been in the business for 174 years.....

[developer9969]

oh well - we can all have dreams and expectations .. but than there is reality - pointless discussion -

[idexus]

I've been in the business for 174 years.....

I see the discussion is starting to be somewhat low-level, which is a shame. I don’t think it’s pointless at all, but I’ll pass, thank you.

[tjiakwokyung28]

one thing that is certain is that "please, stop xaml" is a windows programming person with a basic level, so he is used to doing drag and drop programming. please stop this useless discussion.

[jingliancui]

https://github.com/dotnet/Comet

I remember this project was created sometime ago. MVU may help you.
BTW I think the answer is not only one side should be killed,Right? Due to there are xaml developers in the world who may not want only c# code.

[saint4eva]

Comet is not actively developed at the moment. However, Maui Reactor UI is very actively developed and used in production. So, that should be preferred C# MVU solution you need.

But xaml should be invested in to make it more modern and appealing to new developers.

[RobTF]

It's a good point - businesses aren't going to want to rely on someone's homebrewn UI framework with little to no support. MAUI's UI stuff has teeth simply by virtue of the fact it's Microsoft and there is (at least on paper) an official support story.

That said, the whole stability debacle mixed with the Xamarin EoL shenanigans really shook that reputation with us. We're working hard to rebuild that internally.