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

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

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

---

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