Drop XAML in favour of using .NET language directly and introduce separate VS extension to outsource XAML support

[SetTrend]

Proposal: Drop XAML in favour of using .NET language directly

I suggest to drop XAML/XML and the inflation of compiler infrastructure in favour of utilizing a native .NET language for defining controls and components, just like .NET Windows Forms does.

Summary

Currently, programming in XAML (WPF, UWP, Xamarin.Forms, UNO Platform) is an unwieldy process (see rationale below). Things can be very much streamlined when dropping the current XML overhead in favour of just using intrinsic, native .NET languages to generate and edit designer files (e.g. *.designer.cs, *.designer.vb), just like .NET Windows Forms does.

Using XML to persist objects in .NET (or C++) leads to additional programming, knowledge, build and designer effort which is redundant if plain native .NET language files would be used for persisting objects in native partial class designer files.

Rationale

• When designer people are using the Visual Studio designer, it doesn't make a difference whether object definitions are persisted in XML or any .NET language.
• Designer folks may be using a native .NET language for creating objects as easy as using XML. This becomes particularly true since the invention of IntelliSense and Initializers. Native .NET language syntax is just another flavor of writing objects and properties, which is rather similar to XML file composition.
• The pre-compilation step, which is compiling XML into a native .NET language for further compilation, will lapse.
• The necessity to master and to switch between two domains (XML ↔ native .NET language) will lapse.
• The Visual Studio designer may simply JIT compile the designer file directly from the *.designer.* file.
• MS build and IDE environment programming effort will greatly be reduced.

Comparison XML / C

<Page
  x:Class="GreenStyling.MainPage"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
  mc:Ignorable="d"
  >
  <Grid x:Name="myGrid">
    <TextBlock>Hello, World!</TextBlock>
  </Grid>
</Page>

using Windows.UI.Xaml.Controls;

namespace GreenStyling
{
  partial class MainPage : Page
  {
    private Grid myGrid;

    public void InitializeComponent()
    {
      if (Controls == null)
      {
        Controls = new Control[]
        {
          myGrid = new Grid()
          {
            Controls: new Control[]
            {
              new TextBlock("Hello, world!")   // may be taken from a resource
              {
                Controls: new Control[]
                {
                  ...
                }
              }
            }
          }
        }
      }
    }
  }
}

[sylveon]

Edit and Continue in C++ doesn't work half the time, and I fail to see how it would replace hot reload.

Hot reload dynamically applies change to the Xaml while running the app, but edit and continue:

• Requires to be on a breakpoint: I am not on a breakpoint while using hot reload. The app is currently running and changes to Xaml are instantly reflected.
• Still suffers from long compile times: I'd be staring at a loading bar for 1 minute just because I changed a padding value and the C++ code needs recompiled. Hot reload is instant since there's nothing to be compiled.
• Is language specific (only C#, VB and C++ according to your link) while hot reload is language agnostic.
• Doesn't change existing layout: edit and continue only changes the code that initially lays out the control, but won't change controls that are already created and laid out.

@contextfree AFAIK there are more C++ users of Xaml than there are F# ones, so it makes more sense to target C++ as second language.

[JaiganeshKumaran]

@contextfree @SetTrend You can already delete the XAML files and create controls in code-behind. I fail to see how this improves the development experience. Maybe a template for code-behind control creation can be made for those who don't want XAML.

[SetTrend]

This thread is not about dropping XAML from the development experience. It's about fully dropping XAML from runtime and build time. It's simply plain redundant in these phases and tremendously (and unnecessarily) thwarting build and runtime.

From many of the comments in this thread, I realize that most commenters here don't know about how computing and compilation actually works behind the scenes. These comments are not valuable and I don't have the resources to reiterate the missing knowledge over and over again on my own.

To get on with my work, I have to refrain from further commenting here, unless my constructive assistance is required, which I will willingly provide. Please bear with me.

I'd still recommend to fully study my above comments, particularly 1 and 2.

[JaiganeshKumaran]

@SetTrend This is simply unwanted. Microsoft should close this right away. XAML makes everything much easier to design, develop and distribute (makes add-ons and extensions easier). XAML reader is already pretty efficient and designer files will slow down compilation time for C++ projects. Create a XAML project in C++ and build and you'll understand why designer files are not suitable.

[SetTrend]

@Jaiganeshkumaran:

XAML reader is already pretty efficient

Efficient or not - it's redundant. And you forget that, in order to create the corresponding object tree, the XAML needs to be expensively parsed.

If you like to add extensions to programs: Just pre-compile and distribute the full object tree in a DLL.

designer files will slow down compilation time for C++ projects.

No, they don't. You tend to forget that designer files are currently already present in XAML C++ projects - plus they are getting generated each time with every build today, which is redundant.

As I wrote before, I don't like to discuss denial of present technical reality over and over again.

[JaiganeshKumaran]

@SetTrend They will slow down compilation. Designer files are already present but they are only re-compiled when you change your bindings. Now with this proposal, even a simple margin change will recompile the entire file which may have more files included.

[SetTrend]

Have you ever seen a file depending on a designer file, except for the code-behind file? How large should this file tend to get in order to have any timely impact?

[JaiganeshKumaran]

@SetTrend Actually not but the other way is true. Create a ViewModel and Bind it, XAML designer file will include it as well.

[JaiganeshKumaran]

I like the idea of precompiling XAML controls but replacing XAML files and adding them to .gitignore is not the right solution. XAML designer should not be a front-end for the designer file, the designer file needs to be separate from the XAML file. This is needed for XAML design tools other than Visual Studio like XAML Studio and Figma. The designer file should be only generated when you build the project and the XAML compiler should do its job. Both XAML reader and XAML designer code-behind files can be supported.

[sylveon]

No, they don't. You tend to forget that designer files are currently already present in XAML C++ projects - plus they are getting generated each time with every build today, which is redundant.

@SetTrend The currently generated files are small and only need to be recompiled when bindings change. Your suggestion replaces it by a massive file that needs to be entirely recompiled for each change. It will affect build times by a significant margin.

[JaiganeshKumaran]

Maybe just like .NET Native, there could be an option called XAML native which precompiles XAML markup instead of using XAML reader at runtime only in release build. XAML files still need to be the primary way to design your application.

[mdtauk]

Xaml files can already be compiled down to XBF (Xaml Binary Files). *.designer files are not designed to be edited or read by people, and are a construct by Visual Studio for it's workflow.

Xaml is not just an intermediate output from a design surface. It is human readable, human editable, and a defined markup language which other tools can output as, or read in.

If anything should go, it should probably be this designer file system, but that is something for the Visual Studio and SDK teams, as these files are the intermediate step that is abstracted from the Design process, and the Coding process.

[SetTrend]

Xaml files can already be compiled down to XBF (Xaml Binary Files).

Yes, yet you seem to ignore that these XBF files still are required to be parsed and costly be instantiated by means of Reflection at runtime.

What is your list of benefits comparing XBF files to pre-compiled code?

I believe it has become clear that XAML is only beneficial for humans (well, only the part belonging to the designer people group), but neither for any compiler nor runtime. Anything done at runtime by XAML can be done with pre-compiled code or, in exceptional and extremely rare circumstances, by well-thought dynamic creation of object trees ad hoc (which is what XAML actually does, yet scattershot and costly using Reflection).

*.designer files are not designed to be edited or read by people, and are a construct by Visual Studio for it's workflow.

What is your immutable objection against them being edited by people?

Admittedly, the current *.g.* files are not easy to grasp or read. (And due to the fact that they currently need to cooperate with a corresponding binary XAML file at runtime, their code is, well, sort of awkward.) But I don't see no reason for not getting them generated in a better, more concise and robust fashion after XAML support has been stripped. I gave two examples of a readable style above. And have a look at WinForms *.designer.* files. They can swiftly be browsed and understood by everyone who's barely acquainted with the target programming language.

For all others, there would be ...

1. the proposed Visual Studio designer (handling *.designer.* files), and
2. the proposed Visual Studio extension, which would still allow those who will be installing it to work with XAML files during the design phase of their product.

In the end, designer files are just a simple collection of object creation statements. There's nothing to it.

As a side note: Compared to XAML files and their ubiquitious closing tags, designer files can even be more concise in the end.

Xaml is not just an intermediate output from a design surface. It is human readable, human editable, and a defined markup language which other tools can output as, or read in.

OK, so ...

1. why should code executed by a machine rely on human readable files for its intrinsic execution? You seem to be intermixing compiled code with interpreted code.
2. what's keeping these tools from, instead, generating pre-compiled CLR/WinRT output, loaded at runtime dynamically?

3. a NuGet package could be provided that's reading XAML files and generating object trees from it dynamically in the corresponding target runtime. So, tools still feeling this could be beneficial to them could include such package into their code.

   Yet, due to the intrinsically poor XAML runtime performance, I suppose tool authors will find they don't need to and should be discouraged from taking this approach unnecessarily.

   Anything that can be provided as BAML/XBF files may better be provided as pre-compiled CLR/WinRT code without any XAML logic or dependency.
   

Can you give an example of a tool - or a human - that won't be able to be seamlessly working in accordance to my above given statements and to my proposal?

[sylveon]

Xaml is native code and therefore doesn't use reflection to create and configure types (that doesn't exist in C++), but rather WinRT activation (which is the normal way to activate WinRT types, so compiled code would provide no benefit here) and then uses precompiled IXamlType structures, not costly runtime reflection. Of course, that's only for custom types. It's highly likely that the XBF parser skips all of that when it encounters built-in types.

Also why a NuGet package over the built-in XamlReader class? NuGet is horrible for C++ and I would rather avoid it at all costs.

[tim-weis]

I'm still wildly confused what is to be gained by approaching a problem that is declarative in nature (UI layout) with a tool that's imperative (code). To me, this all looks like choosing the wrong tool to solve problems, that—for the most part—have been misidentified.

While you may subscribe that to opinion or preference, this proposal consistently ignores technical realities. A recurring theme is the assumption, that a 1:1-mapping between code and a visual designer exists. It is thus unfortunate to realize, that C++ has no less than 19 different ways to initialize a variable. This puts the visual designer in a position where—on average—it makes 18 out of 19 developers sad. How do you explain to those 18 sad developers that they are winners after all?

I'm sure you have posted this proposal in good faith, and genuinely believe that it addresses very real issues. Although I'm still not able to see a comprehensible problem statement nor a proposed solution that would be even remotely feasible for clients that cannot take a dependency on .NET (like WinUI).

[brabebhin]

Even with C#, and even with devs writing UI, I don't see why you'd ever want to drop XAML files. Sure, there's a learning curve, but once that's overcome, XAML becomes just so much more powerful. It saves you an incredible amount of boilerplate code. Have you ever tried doing a medium to complex UI with just code behind? With something along the lines of hundreds of elements, with different levels of nesting? What goes in the XAML file would probably need to be split across several hundred files just to keep the things manageable. You may not see the benefit for simple UI (sometimes I skip XAML for those as well!) but for complex UIs, there is no way around it. There is a reason all successful platforms expose markup (XML, HTML, XAML etcML) for UI. It is a tried and tested approach which has withstood the test of time.

[SetTrend]

Sure, there's a learning curve

No, there's no learning curve. Once you know XML you know XAML. Once you know the corresponding runtime, you know XAML, too.

If you don't see the plain useless computing overhead that's included with XAML, I guess there's still a learning curve ahead of you.

XAML becomes just so much more powerful.

Are you working for an advertising agency? So, what's the specific advantage in writing an object tree in XML compared to any other language?

It saves you an incredible amount of boilerplate code.

No, it doesn't save you anything. It's just code written in XML than in a native code. Plus, there's a transpiler involved, translating XML into native code.

Have you ever tried doing a medium to complex UI with just code behind?

Sure, I'm an experienced software architect. Have you ever read or debugged any Windows Runtime code involved with XAML?

What goes in the XAML file would probably need to be split across several hundred files just to keep the things manageable.

You're cracking a joke here, aren't you? So, you're saying that

<A b="c" d="e">
  <B f="g" h="i">
    <C j="k" l="m"></C>
  </B>
</A>

... is so much more to write than ...

  A a = new A() { b: "c", d: "e", _: new B()
                  { f: "g", h: "i", _: new C()
                    { j: "k", l: "m"
                    }
                  }
                }

Please, give a contradicting example.

but for complex UIs, there is no way around it.

Nonsense.

There is a reason all successful platforms expose markup (XML, HTML, XAML etcML) for UI. It is a tried and tested approach which has withstood the test of time.

Please do list "all successful platforms".

Please refrain from adding more of this nonsense content to this thread.

[brabebhin]

I'd say your aggressiveness comes from the lack of experience. All your examples so far have been little toy UIs that serve your purpose and have 0 applicability in the real world.

Try writing a UI like calculator or groove music using only code behind, and then come back to this thread and report the findings. 👍

[sylveon]

You're cracking a joke here, aren't you? So, you're saying that ... is so much more to write than ...

Equivalent in C++.

C c;
c.j(L"k");
c.l(L"m");

B b;
b.f(L"g");
b.h(L"i");
b.Content(c);

A a;
a.b(L"c");
a.d(L"e");
a.Content(b);

return a;

So yes, a declarative language like XAML works much better.

Please, give a contradicting example.

VisualStateManagers and triggers, complex control templates, compile-time and runtime bindings.

Please do list "all successful platforms".

Android for one uses XML. The web is an obvious pick here too because of its heavy reliance on HTML. Even libraries like React use HTML in JSX to represent the UI.

Please refrain from adding more of this nonsense content to this thread. Try writing a UI like calculator or groove music using only code behind, and then come back to this thread and report the findings.

Please keep this civil.

[brabebhin]

Well Android isn't the best example unfortunately. In my experience, it still requires a lot of glue code (it an be easily separated but it is not really the best, I'd say it is an average example). But the entire web is build around declarative HTML, so there's that.

Don't get me wrong, if OP can show an example of real world C# declared UI, then I'm all for it, since this is the biggest impediment to not adopting it. People don't use XAML just for kicks and giggles, they use it cause it makes life easier. If C# / C++ / whatever could be used to declared with just as much effectiveness, I'm sure everyone would jump on board since nobody wants to learn an extra XML syntax.

(Un)fortunately, humanity mostly moved on from imperative languages in UIs, and there's a good reason natural selection worked its magic in that direction. There's still some work to be done in this area, but I'm sure eventually all platforms will move to some sort of declarative frameworks.

[VagueGit]

I was one of the first to argue against the original proposal to drop xaml. The proposal was then reframed to allow xaml as an extension.

The OP offered strong technical arguments in subsequent posts for a dev to be able to choose to not have xaml in a project. Unfortunately some posters appear to have not read those technical arguments and we have seen visceral responses to the title of this post.

The quality of debate might be improved by the OP closing this ticket and opening a new one with a title that is less threatening. I suggest a title that does not have Drop Xaml as the first words.

Perhaps something like "Package xaml as a nuget" with a first paragraph that shows the benefits to xaml users

• Alllow xaml to advance independently of ...
• Allow xaml to be added to other project types
• etc

Having talked up xaml, the OP can then proffer the benefits to those who choose not to include xaml. I'd also advise some cool-off time after closing this issue, before opening a new issue.

The OP will probably still be flamed, sadly, that's what technical forums have become, but hopefully the virulence will subside some. Good luck with your proposal. Here's hoping for more reasoned debate in the New Year.

[Shadowblitz16]

Both should be supported. while xaml separates your GUI from your logic its hard to read and requires you to learn a new language. code generation while it looks nice and is easy for users to edit, it ties your logic to your gui.

This should be up to the developer when creating a project

[andrewleader]

Excellent discussion and feedback! I'm transferring this issue to the WinUI GitHub since this feedback is WinUI/XAML-centric. Excellent feedback though :)

[SetTrend]

I was one of the first to argue against the original proposal to drop xaml. The proposal was then reframed to allow xaml as an extension.

The OP offered strong technical arguments in subsequent posts for a dev to be able to choose to not have xaml in a project. Unfortunately some posters appear to have not read those technical arguments and we have seen visceral responses to the title of this post.

The quality of debate might be improved by the OP closing this ticket and opening a new one with a title that is less threatening. I suggest a title that does not have Drop Xaml as the first words. [...] Having talked up xaml, the OP can then proffer the benefits to those who choose not to include xaml. I'd also advise some cool-off time after closing this issue, before opening a new issue.

The OP will probably still be flamed, sadly, that's what technical forums have become, but hopefully the virulence will subside some. Good luck with your proposal. Here's hoping for more reasoned debate in the New Year.

Thank you, @VagueGit, for your excellent, very constructive and beneficial comment!

Yes, opening a new issue might be useful.

I'm not sure, though, if I will be able to provide as much effort and time into this case when creating a new issue and start the same set of discussion all over again.

Do you believe there is a good, preferred way of curtailing the amount of work I need to supply?

[sylveon]

I think there are a few key points to consider to make the proposal more appealing:

• Consider that C++ is first-party supported, which has significant challenges for any kind of parsing and codegen;
• Consider that XAML currently has performance benefits over laying down controls in code, this should not be regressed (loading a .xbf which is compiled from XAML is faster than manually creating and laying down controls);
• Consider that people do not want to check in auto-generated code in their git repos;
• Consider that people will want to use an IDE other than VS to work on code.

[marcelwgn]

I can only second what @sylveon said. Those points need to be figured out and solved when proposing an alternative to writing UI's in XAML, especially how this would work with other languages and for people that are not using designers. Also ideally, when approaching that topic, there shouldn't be put any assumptions as to how people work or don't work with WinUI. Some use, XAML with Hot Reload, some use the Designer, some use both, some use C#, some use VB.NET, some use C++/WinRT. All those different ways of developing should be respected here (sadly, using the designer with WinUI 3 isn't supported yet...) and not forcing people into one way to develop because the assumption is that everyone works that way anyway (as already mentioned by others here in the thread).

[VagueGit]

However @sylveon if a poster inadvertently fails to consider all issues, that should not draw attacks as they have here. After all, this is a place for discussion. Not everyone in any discussion is going to consider all aspects that might be touched on. That's why we discuss things, to explore what we might have missed.

I've unintentionlly drawn the topic away from the original post. Rather than prolong this discussion off-topic, perhaps any offensive comments should not be discussed other than with a down-vote and a link to GitHub Community Forum Code of Conduct

[fredemmott]

The Xaml compiler is shipped as an exe with WinUI 3

Where is this? I can't find anything handily named *xaml*.exe in the windows app sdk nuget package or otherwise obvious.

which means that you can now use Xaml without even msbuild at all. For example with CMake. Build the code with Clang and edit it code in Sublime Text. Without VS ever being installed.

I've been trying to get c++/winrt + CMake + WinUI3 working without the xaml compiler (partially because I prefer UIs as code, but mostly because I can't find the xaml compiler exe). I can create a Microsoft.UI.Xaml.Application, a Microsoft.UI.Xaml.Window and show them without any XAML - but something about the resources system appears to be tied to the Application XAML.

I can instantiate various Microsoft.UI.Xaml.Control classes, but I can't render them without XamlControlsResources; I can't pass that to Resources() (or Resources().MergedDictionaries().Append()) as instantiating it fails:

Exception thrown at 0x00007FFA07C74F69 (KernelBase.dll) in DemoApp.exe: WinRT originate error - 0x80004005 : 'Cannot find a resource with the given key: AcrylicBackgroundFillColorDefaultBrush.'.

There appears to either be a coupling to msbuild or to the Application having a corresponding .xaml file

https://github.com/fredemmott/cmake-cpp-winrt-winui3/blob/master/src/main.cpp (with c++/winrt and windows app sdk being fetched from nuget via the files in third-party/ in the same repository)

[sylveon]

Where is this? I can't find anything handily named xaml.exe in the windows app sdk nuget package or otherwise obvious.

This was true at time of writing, but is unfortunately not true anymore. The XAML compiler went back to being a MSBuild task DLL. IIRC the executable compiler was always experimental.

I can create a Microsoft.UI.Xaml.Application, a Microsoft.UI.Xaml.Window and show them without any XAML - but something about the resources system appears to be tied to the Application XAML.

I can instantiate various Microsoft.UI.Xaml.Control classes, but I can't render them without XamlControlsResources; I can't pass that to Resources() (or Resources().MergedDictionaries().Append()) as instantiating it fails:

In WinUI, the XamlControlsResources are actually instantiated in the constructor (as part of InitializeComponent()) instead of during OnLaunched, so I would try maybe doing that here.

In worse case, InitializeComponent() just does the following:

::winrt::Windows::Foundation::Uri resourceLocator{ L"ms-appx:///App.xaml" };
::winrt::Microsoft::UI::Xaml::Application::LoadComponent(*this, resourceLocator);

So you may be able to get away with creating a raw XAML file containing just this, shipping it with your app, and then copying the code from InitializeComponent() in your App's constructor

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Application.Resources>
        <XamlControlsResources xmlns="using:Microsoft.UI.Xaml.Controls" />
    </Application.Resources>
</Application>

Hopefully that helps!

[fredemmott]

Thanks :)

In WinUI, the XamlControlsResources are actually instantiated in the constructor (as part of InitializeComponent()) instead of during OnLaunched, so I would try maybe doing that here.

That gives me the same problem - and also, .Resources(with_or_without_an_argument) fails - it seems like the application isn't initialized enough during construction, and ::Start() does a bit more later

So you may be able to get away with creating a raw XAML file containing just this, shipping it with your app, and then copying the code from InitializeComponent() in your App's constructor

That (https://github.com/fredemmott/cmake-cpp-winrt-winui3/commit/f00b0ab9b105aab094e4a036a302a0bfd4f139cd) results in:

The type 'XamlControlsResources' was not found.

That might just be that I need to also implement IXamlMetadataProvider , though that's a little bit more involved (and really wants the xaml compiler)

[sylveon]

Since you don't have XAML metadata of your own, you can just forward to XamlControlsXamlMetaDataProvider

[fredemmott]

Thanks, that works perfectly:

... now to decouple my actual app from wxWidgets :D

To summarize:

• Proof-of-concept app at https://github.com/fredemmott/cmake-cpp-winrt-winui3
• app.xaml currently appears to be required
• msbuild is not required; cmake + C++/WinRT + WinUI 3 works fine
• xaml is definitely not required for the actual window UI part of WinUI 3
• a xaml compiler is not required

[fredemmott]

xaml is definitely not required for the actual window UI part of WinUI 3

So, swapping content is easy, but doing things 'correctly' seems to be appears more closely tied to Xaml than I thought - for example, Frame.Navigate() wants information about a xaml type it can instantiate

I've got the IDL -> winmd -> cppwinrt parts of getting a xaml_typename sorted, but that then gets me back to needing to create an IXamlType, which would usually be done by the xaml compiler.

---

it seems like:

• making winui 3 properly usable without xaml would require WinUI 3 to audit methods that take TypeName parameters, and add overloads that take an already-existing instance. For example, add a Frame::Navigate(Microsoft.UI.Xaml.Controls.Page) overload, so I can construct it myself without xaml and pass it in, without ever needing IXamlType
• making winui 3 properly usable with CMake either requires a separate xaml compiler executable, or doing the above

Thanks again though - I can make this work basically by abusing Content() - and even like that, without fancy transitions etc, migrating is still tempting.

[VincentH-Net]

See C# Markup 2 for a developer-friendly C# Markup API for WinUI 3 (and other .NET UI frameworks as well).

WinUI 3 example using shorthand (for common property value combinations) and a few Flutter-like patterns:

[csharper2010]

The idea of C# markup and other UI libraries like SwiftUI, Flutter and Elm is to have a declarative UI in the programming language the rest of the application is also written in. Some comment above suggested that Xaml is superior because it is declarative falls short because programming APIs in an arbitrary programming language also can be declarative.

The blueprint for code based UI shoul be far away from Windows Forms designer generated code because it is all focused on preparing the whole set of controls needed for the Window and then tweaking the details through switching visibilities and modifying control properties explicitly or with data binding.

The mental shift that is needed in my opinion for programmer friendly UI technology is that user interfaces should be functions mapping a model to a view. No need for item templates, converters or other fancy stuff because an item template is just a function, a converter from model to ui is just a function... It is just code and it should be easy to do without much ceremony. The whole runtime and lifecycle supporting features like components should be hidden behind an API that takes care of instantiation, updates and destruction.

Borrowed from a talk of Don Syme's, there is the example of how it is possible in Xaml to invert a Boolean condition. Needing a Converter to do that seems quite a bit of overkill. Would a UI just be code, so much seems natural in how it can be accomplished.

I hope that the trend of declarative code based UIs really keeps pace and some time Microsoft is willing to make the right strategic decisions in that area.

[sylveon]

The problem with that is C# markup. WinUI 3 supports C++ too so any solution needs to consider C++ as well. It can't be C# only.

The initial suggestion presented here focused on C# only, then adapted the same solution to C++, ignoring all C++ specific issues this solution has (long compile time, very verbose code, very poor edit-and-continue/hot reload support, etc.). XAML never had those issues from the get go: changing xaml requires no code recompile or very little, xaml is less verbose, xaml hot reload works reliably even in C++. I haven't seen any effort from the presented alternatives to XAML to fix or alleviate these issues.

[JaiganeshKumaran]

XAML enables clear separation between UI code and business logic. That does make certain things harder unlike a programming language, as you mentioned a converter is needed even to invert a boolean however for that XAML could have a negation operator (!) and similarly add other common operators to be used.

[saint4eva]

There are some efforts to give us a better way of developing apps using only code. C# Markup is one of them and it is for those developers who love C# and MVVM.

But there are some developers who love simplicity and power and would like to write the entire app in C# and MVU pattern. Both the business logic and UI codes in C# makes development of apps a breeze. Comet helps you achieve that, as it provides MVU pattern and C# for writing end-to-end business and consumer apps

[csharper2010]

XAML enables clear separation between UI code and business logic.

Guess what programming languages allow: the separation of concerns. You can and should have a view model in swiftui and other ui technologies based on those ideas.

That does make certain things harder unlike a programming language, as you mentioned a converter is needed even to invert a boolean however for that XAML could have a negation operator (!) and similarly add other common operators to be used.

Yes, XAML could have such an operator built in but for some reason that hasn't happened in nearly 20 years. If you don't have a separate language, you don't need redundant implementations for such things.

And surely, XAML can and should still be supported...

At some point in time I really had fun learning WPF but the current trend is implementing UIs in a more functional style. The things that really caught me then are the free composability of controls inside other controls, templates and data binding (although I hate INotifyPropertyChanged). But those don't require XAML conceptually. If WPF would be invented now, I guess there wouldn't be XAML. There would be some clever VDOM and diffing mechanism in place that identified the areas that needed to be updated.

[dongle-the-gadget]

You can and should have a view model in swiftui and other ui technologies based on those ideas.

Is it just me or I feel like cramming lots of source code within SwiftUI?

[dongle-the-gadget]

While XAML separates your GUI from your logic, it's hard to read and requires you to learn a new language.

Is it? The syntax is pretty much derived from XML, which is rather popular, and also I find code generated by Winforms designer to be very hard to keep track of.