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[]
                {
                  ...
                }
              }
            }
          }
        }
      }
    }
  }
}

[mdtauk]

Xaml can continue to be supported, whilst also adding in support for Xamarin's C# UI

https://devblogs.microsoft.com/xamarin/c-sharp-markup-for-xamarin-forms/

Basic Example

Grid grid = new Grid();

Label label = new Label { Text = "Code: " };
grid.Children.Add(label, 0, 1);

Entry entry = new Entry
{
    Placeholder = "Enter number",
    Keyboard = Keyboard.Numeric,
    BackgroundColor = Color.AliceBlue,
    TextColor = Color.Black,
    FontSize = 15,
    HeightRequest = 44,
    Margin = fieldMargin
};
grid.Children.Add(entry, 0, 2);
Grid.SetColumnSpan(entry, 2);
entry.SetBinding(Entry.TextProperty, new Binding("RegistrationCode"));

Content = grid;

https://docs.microsoft.com/en-gb/xamarin/xamarin-forms/user-interface/csharp-markup

[VagueGit]

We have a design team as well as a dev team. Our designers work in xaml. They aren't devs.

This is how presentation frameworks were intended to be used. Devs are not generally good at UX. Designers are good at UX, but designers aren't devs.

[SetTrend]

@VagueGit:

Yes, I comprehend. Yet, even designers can switch vom XML to C# (or, if they prefer, VB.NET). There's no particular additional knowledge required if they stick to *.designer.* files.

See my code sample above. There is not a significant difference between the XML and the C# version. Both indent the same way.

Given the new C#8 features, the C# code may even be more concise.

Just give it a thought. That's all I ask.

[mdtauk]

@VagueGit:

Yes, I comprehend. Yet, even designers can switch vom XML to C# (or, if they prefer, VB.NET). There's no particular additional knowledge required if they stick to *.designer.* files.

See my code sample above. There is not a significant difference between the XML and the C# version. Both indent the same way.

Given the new C#8 features, the C# code may even be more concise.

Just give it a thought. That's all I ask.

XAML can be consumed by other tools like Figma which designers use, and can be human readable without any knowledge of programming. They are also separated from the code files, so can be imported from a different team.

Swift UI and C# UI are the same kind of solution for the same issue - but I think there is a place for both XAML and C# - and when compiled, they become the same set of Direct X instructions to the renderer.

[VagueGit]

Our designers wouldn't adopt C#. They aren't devs. They are arty types. They do most of their work in a tool like Illustrator then they map it out in Blend. They tweak the xaml but they don't write all the xaml themselves.

In a shop that didn't have designers we wrote a lot of our layout in C#. It was ok, but I'd never want to go back. Proper designers light up your work. You sell more software. Designers pay for themselves many times over.

So yes, I get what you are saying and I agree devs should have the option to write their designs in code. But without the option of designing in xaml, Project Reunion would lose shops like ours.

[JaiganeshKumaran]

@SetTrend Please don't. XAML is easier to separate UI logic and code behind and makes UI designing easier. You can already use C# GUI if you want from Code Behind and even get rid of the XAML file.

[sylveon]

Using C# to layout controls rapidly explodes in size when more complex scenarios are required, and renders the application of MVVM even more boilerplate-y (have to manually subscribe to PropertyChanged and update elements instead of using Binding or x:Bind). WYSIWYG editors like WinForms are an absolute pain for source control as well.

Not to mention that this whole idea would be terrible for C++ usage, which WinUI/XAML supports.

[tbolon]

I think it's also really hard to maintain a designer which interacts with c# source code in both directions. The generated code must be left untouched for the designer to work properly. So it's mostly a relation "Designer to Code" as you are not supposed to change the code manually and expect the designer to understand your changes.

The designer has to analyze the source and interpret instructions, and transform designer manipulation into code in the designer files.

So what is the gain of having the c# source code available ? You are not supposed to manipulate it, or even know it exists. So it's an implementation detail.

And about the fact that the .xaml.cs is not available ? It prevent you from having two files in your source control (.xaml and .xaml.cs) which could be manually edited and generating complex merge conflicts.

[saint4eva]

We have a design team as well as a dev team. Our designers work in xaml. They aren't devs.

This is how presentation frameworks were intended to be used. Devs are not generally good at UX. Designers are good at UX, but designers aren't devs.

Fortunately, Flutter and SwiftUI devs can design very well. Windows team should give us something similar or better than Comet (Maui C# MVU).

[JaiganeshKumaran]

@saint4eva Maybe as an option but XAML should not deprecated

[saint4eva]

@saint4eva Maybe as an option but XAML should not deprecated

Yes, it should be a viable option - writing UI in MVU C# way. Note, that I am not canvassing for the deprecation of XAML. Xaml is especially important and has been for years. But we need something viable in C# for those who love writing the UI in code. e.g. Flutter and SwiftUI - even the upcoming Maui (Comet MVU).

[AathifMahir]

I prefer to have Xaml as default UI and UX rendering engine, Because Xaml is the most easiest and flexible UI and UX Development Framework that i have ever used.

[SetTrend]

Taking your replies into account, I'd like to amend my proposal and propose (and discuss) the following (which is a slight change to my original proposal):

I propose to outsource the XAML part into an extension and drop it from runtime, design-time and build-time.

Let me elaborate on my proposal ...

With such - optional - Visual Studio extension, designers and programmers may choose whether they still want to utilize XAML (by installing the proposed VS extension) or deal with the runtime directly and fast (the expected default).

1. The extension is supposed to transpile .xaml files into *.designer.* partial class files at design time and to keep both in sync (by watching the corresponding folders).

Futher rationale ...

(Please pardon me for the following long essay. I'll try to lighten it up with some animations depicting the corresponding description for better reading.)

• Currently, the VS designer interacts with XAML files. A new VS designer should instead interact with *.designer.* files (this actually works flawlessly with Windows Forms for decades). This approach would be much faster because the XML in the XAML file wouldn't be required to be parsed and matching objects to be found by Reflection for the designer to display its surface. Plus, the VS designer itself would supposedly be significantly more streamlined to implement.

• Currently, in a pre-build step, the build process parses all XAML files and transpiles them into designer partial classes (\obj\**\*.g.*). This pre-build step can be completely omitted, and (like with Windows Forms) standard *.designer.* partial classes may be used, maintained by the new VS designer (mentioned before) that's manipulating native .NET language code.

---

Removing all XAML parts from current XAML project types (e.g. WPF, WF, UWP, Xamarin.Forms, Uno Platform) would greatly reduce the current overhead for dealing with XAML:

1. The Visual Studio designer could JIT compile its partial *.designer.* files and run them immediately to display its surface ‒ instead of being required to parse XAML, find the corresponding objects via Reflection and trying to instantiate each of the objects manually.

2. The compiler could just compile the *.designer.* partial classes along with the user defined partial classes. No additional pre-build step would be required to transpile XAML to native .NET language code by parsing the XML, finding the corresponding objects via Reflection and derive code for each of the objects manually.

3. The Windows Runtime wouldn't be required to read and parse BAML/XBF files at runtime and find the corresponding objects in memory to complete the object tree.

---

Benefits are ...

• Faster development
• Faster build
• Faster execution
• Windows Runtime code can be reduced
  (thereby reducing Microsoft development and maintenance time and cost)
• Visual Studio designer code can be reduced
  (thereby reducing Microsoft development and maintenance time and cost)
• The Visual Studio Blend product may be deprecated
  (thereby reducing Microsoft development and maintenance time and cost)
• By implementing a new, separate, optional XAML extension, all project types that support *.designer.* files may optionally support XAML, even Windows Forms.
• Designers who prefer to use XAML/XML may use the proposed extension and won't notice the difference.

---

The proposed extension is supposed to provide the following functionality ...

1. The extension provides a file watcher that's syncing XAML files from *.designer.* files and vice versa.

---

[mdtauk]

I don't agree with removing XAML as a core part of WinUI and Windows App Dev.

Sure allow the new C# Markup UI to be integrated and a supported option - but it will use XamlDirect in the background and for UI rendering - as will ReactNative for Windows.

If you wish to use C# to create your UI, more power to you, but it will still push down to Direct X for rendering.

[SetTrend]

@mdtauk: And that's exactly the wrong way around. Going from C# to XamlDirect and then back to .NET isn't truely efficient.

Windows 10 is currently most sluggish and greasy. We (i.e. you) should strive to enhance performance significantly.

I don't think it makes sense to use a fast technology like DirectX and then contradict its performance by going back and forth through domains at runtime.

If you see my proposal to outsource XAML to a separate extension, you will notice that there will be a significant performance boost at runtime because everthing happens within .NET (or WinRT).

[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 (fredemmott/cmake-cpp-winrt-winui3@f00b0ab) 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.