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

[mdtauk]

XamlDirect is a low level way of accessing the rendering UI

So you can create the UI from code and C# / C++

Unless you are typing C++ Direct X drawing code, you have to go though this process to put UI on the screen.

What goes away is writing markup which gets compiled and parsed

[sylveon]

How would you compile XAML in CI with this approach? Installing a VSIX is impossible in Azure Pipelines, and I strongly oppose the need to check-in *.designer.cpp files generated by tooling.

I also don't get the core idea - if you want to completely skip XAML and manually layout controls you already can. Create a normal class, inherit from Windows.UI.Xaml.Controls.Page, and knock yourself out by manually creating + laying out controls then setting the Content property in the constructor.

[VagueGit]

@SetTrend Is nice. I like.

[tim-weis]

This fails to acknowledge a core design goal of the Windows Runtime: Language agnosticism. The diagrams look tidy only due to the arbitrary choice of just considering C#.

I don't know how long JavaScript is going to last, but C++ (be that C++/WinRT or WRL) and Rust provide very real Windows Runtime projections. Once you include those in the considerations, things get much, much more complex than the diagrams suggest.

Another aspect that seems to have been ignored: XAML isn't just about UIs. It's much more fundamental, and can be used anywhere you need to instantiate objects and assign properties to them. I've frequently used XAML to inject mock implementations for automated testing, for example, and I'm sure others have used XAML in ways I didn't even imagine.

With all that I feel that this proposal takes too narrow a view by just considering C#. We've been there before, with the XAML compiler too intimately intertwined with C#. This led to much fragmentation, grief, and (in part) to making C#/WinRT a necessity. Let's not repeat history.

[tbolon]

• A new VS designer should instead interact with *.designer.* files (this actually works flawlessly with Windows Forms for decades).

I don't agree with that, and I am sure this solution was abandoned long ago for valid reasons. I am not a MS member, but I am convinced the codebase which manipulates the winforms code-behind file is a monstrous beast that no one wants to interacts with ever. Having to read code to interpret what to render in the UI is a really complex problem. The difference with other framework is the requirement to have a designer (and not a simple readonly UI), so it means you have to interact in both directions between the code and the designer. So an intermediate DSL was created, aiming to provide a simple way for a designer to interact with the UI. Then, a code file can be generated in the end.

Perhaps, with roslyn you could now approach this problem with a better tooling, but still, having to read and interact with source code for a designer to work is very perilous task IMO.

Also the fact that you have to create a new designer when you want to support another language (VB, F#) increase the cost. Having an intermediate DSL means that you only have to create a component that transform this DSL into code one way.

[SetTrend]

@sylveon:

How would you compile XAML in CI with this approach?

You don't. CI uses the *.designer.* files.

The proposed XAML extension would merely exists for designer persons not utilizing the proposed new VS designer and not using the project's native .NET language in the exceptional case the designer doesn't fit their needs (you usually don't edit *.designer.* files manually).

Installing a VSIX is impossible in Azure Pipelines

That's unnecessary, as I explained above.

and I strongly oppose the need to check-in *.designer.cpp files generated by tooling.

So, then you also object to committing project and solutions files, generated by tooling? ... or to XAML files, generated by the current VS designer?

I also don't get the core idea - if you want to completely skip XAML and manually layout controls you already can.

This is not about the requirement to generate layout manually. See my previous message: "A new VS designer should, instead, interact with *.designer.* files" (... as opposed to XAML files).

@tbolon:

Actually, The designer file's code is incredibly concise. Have you ever created a WinForms project and examined the *.designer.* files?

Frankly, it's no difference to the XAML content. It's just written in another language. What is your concern? Why should the *.designer.* file contain anything else than the XAML file does? What would be the additional information to store? "Hello, world!" is always "Hello, world!", no matter which language you choose. Using a native language is just incredibly faster than always translating from one language to another.
@mdtauk:

Translating from C# to XAML (aka. XamlDirect) and then back to C# is like translating messages here at GitHub from English to Chinese and then back to English. It's, well, plain redundant. And sluggish. And cumbersome.

@tim-weis:

XML had been a fashion hype two decades ago. That's why it had been chosen, I suppose. It had never been advantageous to be used in this context. - AFAIK, hardly anyone is using XML anymore nowadays. The XML era has bygone. It's just a persistence format, nothing more; just like JSON or YAML, which are the current persistence format fashion victims.

Actually, the particular .NET language doesn't really matter here. MSIL/WinRT is the only hard fact that needs to be considered. All .NET languages intrinsically support my suggestion. They need to, because in the end everything is run in MSIL. Either from XAML → native .NET language → MSIL/WinRT; or just from native .NET language → MSIL/WinRT (which is to some regard the core of my proposal).

[sylveon]

So, then you also object to committing project and solutions files, generated by tooling? ... or to XAML files, generated by the VS designer?

• My Xaml files aren't generated by the VS designer, they're hand written. The VS designer generates horrible Xaml, I only use it as a visual reference (and even then that's being replaced by hot reload)
• I manually change my project files as well because letting the IDE do it turns into a mess quickly. Except when simply adding new .cpp files to the solution since the IDE does what I would manually do anyways.
• Solutions are rarely touched, and pretty small. It's easy to review changes to that before commiting or merging.

If WinForms is any indication, designer files will quickly grow to something that's hard if not impossible to review, especially when complex GUIs are involved. I don't want to sift through thousands of lines of ugly designer generated code being commited to review a PR adding a new control/page when I could be reading a 100 lines Xaml file.

@tbolon makes a good point as well. C++ is incredibly complex to parse, so the "just reparse the code behind" approach either would be extremely fragile because it's not using a proper compiler, or use a compiler and take a ton of CPU time/memory (especially when cppwinrt is involved, and with Xaml cppwinrt always is)

[SetTrend]

@sylveon: If you don't agree to designer files, then just utilize the proposed extension. With it you can continue to manually maintain XAML files (which tend to become huge and hard to read when they grow, too).

[sylveon]

Which circles back that I can't install it in CI.

[SetTrend]

In CI you don't edit. The CI builds by itself. You edit in Visual Studio or similar IDE.

Please re-read my proposal.

[sylveon]

The extension will have to generate the .designer.cpp files, and I won't check in those. Therefore it's required to build.

[JaiganeshKumaran]

The beauty of XAML is that it separates business logic and UI code. If you have seen the WinForms designer file, you will notice it has everything for creating controls. With XAML, other than x:Bind and x:Name, the controls are created at runtime allowing WinUI to optimize the performance which you can't do when you create XAML controls via code-behind. You don't need the designer file to see how the controls are created. UI assets can be easily loaded and parsed via XamlReader and also you can easily define resources which can't be done with WinForms. For example XAML helps me to embed UI from an app extension which is not so easy in WinForms with the pre-generated designer file.

[SetTrend]

@sylveon;

The extension will have to generate the .designer.cpp files, and I won't check in those.

No, given my proposal, you will commit exactly these file, and you won't commit XAML files anymore.

As I wrote before, the extension is supposed to keep XAML and *.designer.* files in sync by using a file watcher. So, whenever you save one or the other with the extension installed, the counterpart file gets updated. So, with the extension enabled, both versions will always be up to date.

CI will build from the *.designer.* files only. ‒ The *.designer.* files will reflect the XAML files' content if you had the extension installed and enabled. Yet, with the proposed solution, XAML files are going to only exisit for your personal comfort, locally on your machine and only due to the extension dealing with them. They won't play any role in the build process or at runtime anymore.

The title says it all: XAML won't exist anymore. Not in the build process nor at runtime. So CI/CD and the user will neither need XAML files nor the extension. If you choose to continue working with XAML files, the extension will create these XAML files only for you and transpile them to the corresponding *.designer.* file whenever you update a XAML file.

According to my proposal, XAML files will become artefact files, only used locally by you and the extension. XAML files may not even be used by one of your team members. So, they may even be added to .gitignore. The proposed extension will restore them to your local copy of the repository whenever you open the project from the *.designer.* files (in case the XAML files may be missing).

@Jaiganeshkumaran:

You shouldn't intermingle data-binding concepts with the use of a persistence language file type. Whatever can be done in XAML can be done in a *,designer.* file. The current build process actually does exactly this. Please refer to the second bullet point above the first animation from my above proposal.

[JaiganeshKumaran]

@SetTrend Yes data binding is done in a code-behind file but XAML can be dynamically loaded by using Binding instead of x:Bind which is not possible with .designer files.

[SetTrend]

Would you mind giving an example, please?

[JaiganeshKumaran]

@SetTrend Let say there's an add-on with some XAML styles and resources. Today you can just use XAML reader at runtime to load these new add-on resources after the actual app has been compiled. Note that not all XAML files have a code-behind. For example, ResourceDictionaies don't need a code-behind to work and can be loaded and unloaded at any time to improve app performance and to reduce memory usage. Also, compile times will suffer especially in languages like C++ which needs the compiler to parse thousands of code-behind files even for a simple blank app.

[SetTrend]

• This may be a rhetorical question: How are ResouceDictionaries stored in memory after they have been loaded through a XAML reader?
• Which thousands of code-behind files do you refer to that need to actually be compiled at build time because they may change due to your programming efforts?

[JaiganeshKumaran]

They need to, because in the end everything is run in MSIL. Either from XAML → native .NET language → MSIL; or just from native .NET language → MSIL (which is to some regard the core of my proposal).

No the Windows Runtime is not only for MSIL and the CLR. WinUI is fully native C++ and no CLR required. Xamarin forms and Uno can benefit from designer files because it's CLR but not for UWP apps.

[SetTrend]

Yes, please take this as given. In my original reply I wrote WinRT, but accidentally deleted it in an update. I'll update my above answer now accordingly.

[JaiganeshKumaran]

• This may be a rhetorical question: How are ResouceDictionaries stored in memory after they have been loaded through a XAML reader?
• Which thousands of code-behind files do you refer to that need to actually be compiled because they may change due to your programming efforts?

• When it comes to WinRT, the system activates the specified RuntimeClass types in the file. For example, declaring AcrylicBrush will activate Windows::UI::Xaml::Media::AcrylicBrush with the specified property values filled. It also caches many types to speed up usage. On CLR platforms, it is the same but it creates a new instance of that CLR type.
• For C++ apps, you need to include a lot of headers just to get basics right. C++ is a complex language to parse and these WinRT headers are highly templated which makes compile time very slow compared to CLR languages

[JaiganeshKumaran]

Since resource dictionaries don't need code-behind files, you can easily update them without a rebuild in many cases and also provides the ability to create asset only add-ons. Hard coding control properties in a designer file may sound more efficient but it's not.

[JaiganeshKumaran]

Instead of reading at runtime or creating a designer file, the current XAML compiler itself could generate the creation code but in a separate assembly. XAML designer and Blend are awesome and are much better than the old WinForms designer and can function the same. XAML makes it a lot easier for designers to work on the UI at the same time for developers to manage business logic.

[sylveon]

No, given my proposal, you will commit exactly these file, and you won't commit XAML files anymore.

Then I categorically object. Sources of truth (the code the developer edits, in this case the .xaml file) should always be checked in and version controlled. Other contributors might want to work on the Xaml code too. Automatically generated code from these sources of truth should, in preference, never be committed since they are a needless burden that can be regenerated. You don't see me committing the ~100mb of source code that C++/WinRT automatically generates for my projects but you do see me committing the .idl file that generates those. Same principle.

Designer files do get really ugly. I've written a tool to diff them in a reasonable matter because the WinForms editor would completely reorganize the file, leading to massive & unreadable diffs, for something that is actually a 2 line change.

Not to mention killing Xaml as first-party means killing hot-reload, since the compiled layout data can't be edited at runtime anymore.

Changing .designer.cpp files involves recompiling the file. Going through a minute-long (or even 5 minutes, on my laptop) recompile because I changed a single padding measure by 1 pixel (this WILL happen in C++, C# isn't the only language in play here) because Xaml & hot reload is gone is an horrible downgrade I simply won't accept. This isn't a case of weak machine (Ryzen 3700x), it's just how C++ is.

[JaiganeshKumaran]

The Visual Studio Blend product may be deprecated

How dare you? The blend is an amazing UI designer and allows you to do a lot that can't be done with the VS designer like retemplating control styles without digging around generic.xaml, adding custom animations with minimal effort etc...

[JaiganeshKumaran]

There could be an option to generate designer files from XAML in your project but WinRT should still support runtime loading when needed.

[tim-weis]

Actually, the particular .NET language doesn't really matter here. MSIL/WinRT is the only hard fact that needs to be considered. All .NET languages intrinsically support my suggestion. They need to, because in the end everything is run in MSIL. Either from XAML → native .NET language → MSIL/WinRT; or just from native .NET language → MSIL/WinRT (which is to some regard the core of my proposal).

This is wrong. The Windows Runtime has a 100% native ABI (and native really means native). .NET is a dependency, and one that some cannot take. None of my UWP projects have a dependency on the CLR, for example. I'm sure the WinUI team isn't taking that dependency either. Nor the team behind the Calculator, or the Windows Terminal.

It's a fallacy to think there were any MSIL/.NET/CLR in the Windows Runtime. There isn't, and any solution that assumes there were is going to repeat past mistakes.

[sylveon]

I am not either. My entire app is coded in C++ and uses XAML Islands: taking a dependency on .NET would increase my memory usage threefold.

[SetTrend]

In the previous discussion I've been focussing on *.designer.* files only. This was a mistake of mine, because these would only apply to XAML files representing visuals.

In order for the suggested extension to also work with ResourceDictionary files and the App.xaml file, I further propose to name these kind of files: *.xaml.*, so the proposed extension may recognize them.

I created a montage of what an UWP app might look like without the extension after XAML would have been removed from the standard framework/build/designer:

---

And this is what it should look like with the proposed extension enabled:

---

The main difference is the additional XAML files in the solution as it is depicted in Solution Explorer:

[tim-weis]

This all reads like, although posted to the Project Reunion repository, it is really a proposal contributing to the Project Fragmentation effort.

It's proposing to replace an interface that's compatible with any programming language (XAML), with one that's specific to a single programming language, specific to a single IDE, specific to a single set of possible external dependencies.

If this proposal is meant to improve the Project Reunion cause, it needs to come to terms with the following:

• The Windows Runtime is a native ABI.
• .NET is a special client of the Windows Runtime only in so far as it forces an external dependency on its clients.
• Any change needs to work for all supported programming environments; this repository's README explicitly names "C++, Rust, C#, and JavaScript".

To this point, this proposal fails to acknowledge, that

• .NET is an external dependency.
• there are programming languages other than C#.
• other programming languages are substantially harder to parse than C#.
• other programming environments are substantially inferior in tracking changes to source code than C#, and thus a change to what is an asset would ultimately lead to insane amounts of times for rebuilding.

[SetTrend]

What makes you believe this will only be working with a single language? Why do you believe it's specific to a single IDE?

Actually, I'm not proposing anything that's not already there. It's currently just, well, sort of put at the wrong place.

Have you had a look at the obj folder yet? What do you see there after you've performed a build? Particularly when you examine a UWP project - which is based on WinRT. It's actually the *.designer.* files created from the XAML files in a pre-build step. The name ending of these current *.designer.* files is *.g.* and *.g.i.*, resp. So, it's already there. Part of the proposed functionality is state of today. And, yes, it works. Is, what you currently find in that folder, not compatible with WinRT?

If, what you find in the current obj folder, is compatible with WinRT, and if, what you find in the current obj folder of a WPF project, is compatible with any .NET language - then your statement is, well, not correct.

BTW: Does {x:bind} work with WPF? Is there a <DockPanel> control in UWP? If both isn't true, then XAML is not as compatible as you're claiming it to be.

[sylveon]

What makes you believe this will only be working with a single language? Why do you believe it's specific to a single IDE?

I mean, the entire thread has been about

• Replacing Xaml which can be edited with any text editor for a WYSIWYG editor that has been referred to as "VS designer", implying it's a VS only thing.
• Using a VS extension for those who still want Xaml.

This screams IDE specific to me. The Xaml compiler is shipped as an exe with WinUI 3, 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.

Unless your suggestion is to write an extension for every editor out there? And now have to deal with a fragmented ecosystem because every extension will have its own quirks.

You've also referred to .NET as if it was the only possible consumer of WinRT and Xaml, which is false even today.

It assumes that every language is as easy to parse and rebuild. Rust and C++ are two direct oppositions to that, and C++ is currently supported while Rust support for Xaml is something that's on the backlog IIRC. It's incredibly hard to parse C++ and even competent compilers like Clang and MSVC will fail at parsing some snippets, or interpret the same snippet differently. You would have to write code that both parses and emits C++/Rust, which is a monstrous amount of efforts compared to just writing code that emits C++/Rust for x:Bind and using one runtime loader to load compiled xbf. The benefits in runtime performance and memory usage from laying out and creating controls directly in code are also low, so the amount of efforts isn't worth it.

The Windows.UI.Xaml C++ headers are massive and explode build times. Rebuilding .designer.cpp for every single change to the Xaml source or WYSIWYG editor is going to make iteration times slower than they currently are (they're already bad), and even dialog controls in old styled RC scripts don't do that, they only require a relink.

[sylveon]

The currently generated files are for x:Bind, connecting events and accessing objects with x:Name from code behind.

Nobody commits those. Only the compiler and Intellisense has to parse them. They're not regenerated when data in Xaml is changed, unless you add more bindings, events or named controls. Even then, it's easy to compile because it isn't a lot of code.

It isn't comparable to something that suggests that you commit them, they are massive and regenerated all the time, and parsed by the IDE and Xaml extension.

[mdtauk]

I believe the intent is for a design tool like Figma will be used to export XAML which can be added to Visual Studio projects.

It also allows something like Xaml Studio to be able to exist and work with XAML outside of Visual Studio.

[SetTrend]

Just found this on re-reading the comments:

Not to mention killing Xaml as first-party means killing hot-reload, since the compiled layout data can't be edited at runtime anymore.

Have you heard of the Edit and Continue feature of Visual Studio debugger?

Nothing will change in regard to debugging. The same set of files will be used, just differently. And XAML will become redundant, that's all

[contextfree]

• It seems like this should be a WinUI issue rather than a Project Reunion issue. Arguably it's an extension of the discussion in this existing issue: https://github.com/microsoft/microsoft-ui-xaml/issues/804

• I don't think multi-language support should preclude doing special work to improve for particular languages, if there's enough value to it or demand for it. In this case it could take the form of additional features in the C# WinRT projection, coupled with new WinRT metadata/attributes that would be applied to classes that are XAML elements. People working on projections for other languages could potentially find ways to use the same metadata to improve their own WinUI developer experiences, but I think it's ok if C# is the primary design point (though it might be worthwhile to use improving F# support as a second target?)

• A general point about the evolution of WinUI: The most common complaint or worry I tend to see about WinUI and Windows/Microsoft UI frameworks in general on forums like Hacker News or twitter is that there have just been too many of them and Microsoft hasn't stuck with any for long enough, so adopting a new one like WinUI isn't safe as they could just pull the rug out from under you. So in making major changes, it's important to maintain continuity for existing developers and code so to avoid the appearance/reality of a "reset."

• • I think the evolution of the C# language is a great example of how it's possible to maintain continuity and still make major improvements over time. If you compare C# 1.0 and C# 9.0, there have been vast changes, incorporating ideas from paradigms "alien" to the initial release like functional programming and dynamic languages, and yet they've largely built on, extended and recast existing features so there's never really been a sense of a break from previous versions. It would be nice if the evolution of UI frameworks could be more like that.
• • WinUI already allows multiple ways of constructing UI, either in XAML, in code in C#, C++ or other languages, or even using a wrapper framework like Xamarin/MAUI or React Native via the XamlDirect interfaces. So rather than thinking in terms of either adding yet another separate method, or killing one, I think it would be better to frame whatever changes are contemplated as simply improving the experience of one of the existing methods - constructing UI in C# code, something which is already possible but cumbersome.