[Discussion] XamlIL as xaml compilation backend

[maxkatz6]

What would you like to be added:

This issue is just to tell you about the existence of XamlIL.
It could be good for Uno, but it also could be unnecessary or wasteful.

Why is this needed:

• XamlIL is faster, than System.Xaml
• Produces IL instead of C#/VB, so potentially can be used with F#
• Should be more linkable and useful for WASM
• For more consistency with Avalonia (at least on Xaml stage)

For which Platform:

• iOS
• Android
• WebAssembly
• WebAssembly renderers for Xamarin.Forms
• Windows
• Build tasks
• Solution Templates

Anything else we need to know?

I am not experienced with XamlIL, so can't help with questions.
But you can create issue on https://github.com/kekekeks/XamlIl/issues

[jeromelaban]

Thank you for initiating the discussion!

At this point, the way Uno generates C# is tied to lots of tricks made to perform compile time / runtime optimizations (or legacy shortcuts in some cases), and replacing it is not a small task.

We are currently removing some of those shortcuts, but I'm not sure XamlIl will be a solution in mid term, as we're still waiting to see where Microsoft is going to go with WinUI 3.0, particularly with regards to the XBF file format.

As for generating IL or C# from XAML, this is a path that is not always interesting. Generating code adds significant weight of the final binary (whichever the platform) when using mono's AOT, and it also has cold-path runtime performance implications. Loading an intermediate binary format may be still interesting for the overall performance. Again, with this side of the problem, we'll have to make validations using XBF loading.

Also, I'm not familiar enough with the XamlIl parser, but the XAML used by UWP is a bit different from the one used by WPF, and there may be some portions that may not yet be compatible. More validation would be needed there.

[stevenbrix]

We are currently removing some of those shortcuts, but I'm not sure XamlIl will be a solution in mid term, as we're still waiting to see where Microsoft is going to go with WinUI 3.0, particularly with regards to the XBF file format.

@jeromelaban I swear the stars are aligning! I've been looking at XamlIl for WinUI this past week, we've been discussing re-architecting our tooling and build something that is very similar to XamlIl. We don't have any plans to replace XBF, we also can't depend on IL since we have C++ customers, so we wouldn't be using XamlIl as-is, but I think it's a great place to start. We've also heard from customers that being able to debug code-behind is helpful, especially for compiled bindings, so generating straight IL sounds possibly problematic. But I don't feel super strongly there, the fact that it gets F# for free is great :)

[robloo]

Very interesting. I was hoping from discussions a year or more ago Microsoft would be able to use XamlIl as well (I think I saw a repo where you were playing around with things). Maybe that was @jkoritzinsky. Too bad about the C++ support requirements but that makes sense. It's still great to hear from time-to-time Microsoft is actively planning a rewrite for the XAML compiler.

[stevenbrix]

@robloo, yeah @jkoritzinsky and I started some work here: https://github.com/stevenbrix/xamlx-winui

Jeremy was doing some awesome work to enable C++/WinRT generation so that we could use xamlx.

WinUI has taken some shortcuts when it comes to implementing parser features, so supporting XamlX has taken a bit of time. Plus, it's not a fully funded project, just a hobby side project.

[robloo]

Awesome stuff! Hopefully this can get promoted to a full project internally. There are a lot of issues with the existing XAML compiler that pop up here and there. A new compiler could also be shared with WPF. After the initial investment (and a lot of the work is done already) it would significantly lower the long-term maintenance costs. Regardless, I know there are a lot more important things at the moment. Thanks for the details.