[Discussion] How tightly is this coupled to IL?

Hey @kekekeks, I’m looking through the architecture of this and wondering how tightly coupled to generating IL this is? As you know, I’m trying to get an effort started around unifying xaml tooling across all platforms. Both PresentationBuildTasks (WPF) and the UWP markup compiler have tight dependencies on the platforms, so what you’ve done here is incredibly interesting to me 😃.

With WinUI, we have c++ customers to support, so we can’t depend on IL. I also have a feeling we’d need a way to switch out backends so we could continue to generate BAML for WPF and XBF for UWP, IL for Avalonia, etc.

Also, and this might just be me, but all the IXamlIL* types are hard to read, mostly because of the lIL letters in succession. It also makes me think that the whole thing is tightly coupled to IL, which I’m sure is not true, but it’s also hard to get out of my head 😃

[stevenbrix]

@worldbeater just to be clear, I want to keep this conversation going, but I’m not able to make any guarantees at the moment because we really need to focus on WinUI3.

I am personally a big fan of this idea, but there is still some work that needs to be done in order to integrate ~XamlIl~ XamlX into those platforms, such as x:Bind, x:Load, and x:Phase for WinUI. With WinUI3, we just don’t have the time or resources to dedicate to this, as we have other higher priorities, like making sure we have parity with existing experiences.

but it seems like WPF-xaml will be replaced with WinUI-xaml…

@maxkatz6 WinUI should hopefully be able to replace WPF. But that doesn’t mean we won’t make the proper investments in WPF if they have the proper cost/benefit. Primarily, anything that makes the migration from WPF->WinUI easier is an area of interest. If sharing the same core compiler tech is able to provide value in that regards, then that would make the case for moving to XamlX even more compelling.

…which works with COM world. Same for UWP. I am not sure, if it is easily possible or convenient to use xaml complier on c# for that.

There are some other considerations for WinUI as well since we use WinRT (based on COM). There shouldn’t be a problem using XamlX for our .NET customers, but we would have to think about what to do for C++. In general, I think the two things we need to do are:

1. Have a special WinUI transform that used XamlDirect for allocations and property sets/gets. This will dramatically improve performance for many built-in xaml types. Any types that aren’t exposed by XamlDirect would just go through the regular code path.
2. Special emitter for C++

This should be doable, so these aren’t major blockers or anything.

[kekekeks]

The compilation process is basically split into two steps:

1. AST transformations that take a somewhat “raw” nodes that contain only text info extracted from XML and produce an AST tree with resolved properties, calls, etc that can be converted into code
2. Conversion of said AST to MSIL. Currently some nodes emit themselves (usually simple ones like one responsible for {x:Null} while others have separate “emitters” like PropertyAssignmentEmitter since the IL generation logic was too huge to fit into rather small AST node itself .

I’m not really familiar with type metadata that’s available for C++, but if it has types, properties, methods and enums in a form that is easily accessible from C# code, we could make a type system backend based on said metadata and convert the resulting AST into C++ code which could be feed to C++ compiler and won’t require any runtime parser support.

Not sure how compatible it would be with BAML. XamlIl essentially takes a XAML document and converts it into AST that consists of imperative commands like “create an instance of type Foo”, “set the property of created type to X”, etc. Some AST nodes represent local variables.