Discussion: X# / Xaml Sharp / Xaml Code - inspired by SwiftUI

[mdtauk]

Apple announced SwiftUI which replaces an older and much more verbose method of building UI for their iOS, iPadOS and macOS platforms.

This is not something that could be done by time of WinUI 3.0 and so is not a proposal per se, but XAML being XML based, is nothing if not verbose. A lot of effort has been made in recent years to make it possible to write less Xaml to do more. VisualStateTriggers being a massive one replacing the VisualStateManager. There is also a proposal to re-work the Grid panel control, to make it more powerful with less Xaml required.

XamlDirect currently exists aimed at middleware tools which can generate XAML from code, but is there some merit into looking at what SwiftUI is doing to perhaps create an alternative to Xaml Markup, with the same power and flexibility of Xaml, but similar to React Native, providing a less verbose version of Xaml.

What it could be called is anyone's guess - for the sake of this suggestion I call it X#, XamlSharp (perhaps inspired by C#'s use of the dot property syntax)

using xaml;  

xaml page  
{  
      this.backgroundColor = themeResource(ApplicationPageBackgroundColor);  
      this.foregroundColor = themeResource(ApplicationTextForegroundColor);  

      xaml grid[name "rootGrid", rows "*, *, *, Auto, 12epx"]  
      {  
            xaml stackPanel[name "toolbar", orientation Horizontal]  
            {}  
            xaml button[grid.row "4" content xaml bind(_appIcon)];  
      }  
}  

^ Example code is not a suggested syntax, but just an illustrative example

This is a place where anyone who has an interest in simplifying Xaml can share their thoughts, ideas, syntax suggestions

[RichiCoder1]

Adding Ammy UI (http://www.ammyui.com/) as excellent prior art in this area.

If this is something that moved forward, it'd also be great if said code or DSL made doing styles & visual state management CSS levels of easy.

[mdtauk]

Ammy is a good attempt at making XAML UI simpler, but it does lean too much towards CSS than more familiar code based approaches that may be more familiar to Microsoft developers, and would work more seamlessly with current tooling I would expect.

Example from http://www.geldesk.org/

JSON is very popular at the moment, but it is so fickle and easy to break - where as XML is robust but complex and wordy.

Whatever format is chosen, there should be a thought on constructing the UI on the screen decoratively, but an ability to easily manage Templates and Styles either inline or as attached files. At the moment XAML does it all, but it is bothersome to edit for designers, and also verbose for those who prefer to work in code.

[contextfree]

It's already possible to make WPF or WinUI UI purely in code (for example, Charles Petzold's WPF book didn't even introduce XAML at all until halfway through the book) so it might be good to use this issue to call out specific problems with doing this today (bindings and templates for example?)

It also might be worth looking at Fabulous which is an existing project for F# and WPF or Xamarin.Forms that seems along the lines suggested in this topic.

[mdtauk]

It's already possible to make WPF or WinUI UI purely in code (for example, Charles Petzold's WPF book didn't even introduce XAML at all until halfway through the book) so it might be good to use this issue to call out specific problems with doing this today (bindings and templates for example?)

The thing that makes SwiftUI stand out is that it remains declarative in nature, similar to HTML and Markup, but is within the language and syntax of Swift. It is possible to create XAML objects, but the concept of nesting elements, and declaring the properties, bindings, templates and styles are obtuse and not very effective.

[Felix-Dev]

I guess it will come down to available resources at Microsoft. For the forseeable future, I want them to first-and-foremost focus on making XAML less verbose - and there have been countless of proposals over the years how to do just that. WinUI 3.0 is currently blocking most of that work so we need to wait some more months until MS and the community can work together and give XAML a much needed update across the board. Depending on how that will go, we can re-visit your idea, Martin, and potentially look at areas outside of XAML markup to make UI design more efficient.

[Happypig375]

@mdtauk That looks awfully similar to what we can do today:

using System;
using Windows.ApplicationModel.Activation;
using Windows.UI;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Media;
namespace NoXaml
{
    static class Program { public static void Main(string[] _) => Application.Start(p => new MyApp()); }
    class MyApp : Application
    {
        protected override void OnLaunched(LaunchActivatedEventArgs args)
        {
            Window.Current.Content = MainPage;
            Window.Current.Activate();
        }

        UIElement MainPage =>
            new Grid
            {
                Background = new SolidColorBrush(Colors.Blue),
                Children = {
                    new Button { Content = "Hello!" }
                }
            };
    }
}

[Mike-E-angelo]

Adding @VincentH-Net's CSharpForMarkup to the mix as well for reference. https://github.com/VincentH-Net/CSharpForMarkup

FWIW, ATM I think any idea that circumvents a visual designer is a terrible idea but I am keeping an open mind about it. Maybe it will grow on me. 😁

Whatever format is chosen

Ideally, you should be able to choose between the two (or more) formats, for optimal adoption. This is the forward-thinking and .NET-like approach that @cwensley utilizes for his ETO project: https://github.com/picoe/Eto

[dpierangeli]

Ok, it can be an useful addition, but please don't do this:

A declarative UI definition should not be mixed with application logic (my idea).

[maxkatz6]

Avalonia team also discussed about XAML markup alternative: https://github.com/AvaloniaUI/Avalonia/issues/2502

[TonyHenrique]

XAML markup is a advancement. These approaches are limited. .NET and XAML need to move forward and reach those platforms, not the contrary. XAML is a way to instantiate objects and separate 'UI code' from the 'code behind'.

Also give a look at https://github.com/microsoft/microsoft-ui-xaml/issues/740#issuecomment-497947074

[TonyHenrique]

If we look carefully we see clearly the simplicity and advantages of XAML. If XAML runs everywhere, it could be used instead of HTML in lots of use cases. We need to be careful to don't waste time with these pseudo improvements, as some folks may up ending wanting to describe UI using YAML files or JSON...

[weitzhandler]

@mdtauk My 2 cents: I'm happy with XAML the way it is, they should just add plenty of more built-in converters, interactivity actions and markup extensions, an integrated way of C# expressions, and a lot of syntax-sugars to make things less-verbose. But if we're to replace XAML, it's for the favor of a C#-only Dart/Flutter/Razor-like UI. No new languages please. In this case, the WinUI team should work closely with the C# team to see how we can introduce syntactic-sugars to make UI declaration easy and less verbose in C#, as well as rendering, hot load, code generation and previewing.

[Felix-Dev]

There are definitely a lot of possible XAML Markup improvements the team should focus on before thinking about alternative ways to build a UI. Both on the control level (like the new grid proposal) and the XAML language itself like introducing a negation syntax for binding, i.e: IsVisible = "{x:Bind !SomeObject.SomeProperty}" or stuff mentioned in these proposals: https://github.com/microsoft/microsoft-ui-xaml/issues/62 and https://github.com/dotnet/wpf/issues/480 (and there are a ton more)

To sum it up: The focus should be first-and-foremost on improving XAML markup!

[mdtauk]

Offering the choice of building XAML UI in C#, C++, F#, VB, JSON, as well as Xaml markup itself - would allow the developer to choose what way is best for them - as long as it all renders the same.

There is Xaml Direct Microsoft.UI.Xaml.Core.Direct but it is intended for middle-ware tools, is very low level, and hasn't been formalised as a first class way to build an app's UI. (New Project templates, sample code, etc)

I am not averse to Xaml as Markup (but anything that results in less markup and simpler declarations would be welcome) but SwiftUI shows that there are alternatives. No idea if one is better than the other, but it is interesting to discuss the pain points, the aspirations, and to possibly learn lessons from other platform ideas :)

[RyoukoKonpaku]

I do agree with the rest that XAML improvements are of priority first and foremost.

For the sake of discussion on possible alternatives how about talking with the Razor Compiler team? They seem to have a decent compiler already that can parse C# and VB (not too sure if this is still supported on newer razor) expressions in HTML and instantiating C# classes (Blazor Components in this case). It's HTML is actually more like XML as well since Razor is kinda strict with closing tags for their compiler which makes it a good candidate for an alternative. Plus points since it's also an MS product so they can freely communicate between the two if necessary.

Off the top of my head it'd probably be like this? This is assuming we treat Xaml classes as Blazor components so that there's less effort needed to make it work.

@* .csxaml additional code can be done on code-behind .cs or even @code section on razor if supported on this .csxaml *@
<Grid>
    @* Using the new directive support that .razor has *@
    <Grid.Row @Bind:Height="someHeightVariable"
                      @Bind:Mode="Binding.TwoWay">
         <Grid.Column>
             @* Can use lambda or for MVVM be a method on the ViewModel *@
             <Button PlaceHolder="Todo" 
                           @Command="ViewModel.SomeMethod"
                           @Background="ConstantsClass.SomeBrush">
                   Some Button
             </Button>
         </Grid.Column>
    </Grid.Row>
</Grid>

This should be less effort in my opinion that writing a new DSL parser from scratch, but the downside is the razor compiler is biased to C# by default so adding other languages like F# might be a hassle.

[Mike-E-angelo]

I like your thinking @RyoukoKonpaku. Unfortunately, Razor is a templating engine, and the results it generates is a plain text file (or stream) for use to emit to a browser. What we're attempting to do here is describe an object graph that ultimately gets loaded into memory and rendered from there.

For instance, while you do reference a Grid object, there is no way for Razor to know what exactly that is, so there is no way to load it into memory for further processing.

Unless, of course, you're suggesting that we use Razor to create XAML files and then from there we load in the Xaml, which would work. In that case, however, you're doubling the required components to get the view loaded, plus there are other considerations such as debugging. How do you debug a binding that was defined in a template file that created the Xaml file?

Not to say that it wouldn't work. It's a neat idea, but it would be an involved undertaking, IMO.

[mdtauk]

One point I think most of us would agree on, is that whatever emerges should be Human Readable

[TonyHenrique]

I would add that I feel that if we unite and ask for the XAML Standard or a Universal XAML, it would be much better that any attempt to change or improve the XAML.

About the code only approach, the best to do would be invest in F# elmish style and also gjallahorn with a WinUI XAML Type Provider.

Another thing that could be done is to allow XAML literals in C#/F# code. This would enable code like this

let myButton title = <Button Text=title />

[RyoukoKonpaku]

@Mike-EEE Indeed it's not that smooth sailing either. I'm actually referring to Blazor in this case which can detect C# classes as Components in Blazor terms. The .razor file actually compiles into a render instruction set on a class. So I'd assume it's possible to change the generated class from the AST that Razor parses.

@using NameSpace.SomeControls
@inject ViewModel VM

@* SampleComponent.razor *@
<ChildComponent>
    <NestedComponent />
</ChildComponent>

The generated class is this.

// compiled SampleComponent.g.cs
using NameSpace.SomeControls;
# alot of pragmas here since it's generated
public partial class SampleComponent : Microsoft.AspNetCore.Components.ComponentBase
{
    [Inject]
    protected ViewModel VM { get; set; }

    protected override void BuildRenderTree(Microsoft.AspNetCore.Components.RenderTree.RenderTreeBuilder builder) {
        builder.OpenComponent<Namespace.ChildComponent>();
        builder.OpenComponent<Namespace.NestedComponent>();
        builder.CloseComponent<Namespace.NestedComponent>();
        builder.CloseComponent<Namespace.ChildComponent>();
        // ... removed for brevity but basically constructs the combination of 
        // strings (e.g. div, span etc...) and Component which are eseentially just classes
    }
}

So what I'd imagine is that we replace the generated builder into a series of Xaml class instantiations into an object graph via Xaml.Direct middleware. Also remove the ability to use html tags so it does not compile for that.

So from the above it would compile to something like this

// SampleComponent.g.cs
using NameSpace.SomeControls;
# pragmas here
public partial class SampleComponent: Microsoft.UI.Xaml.UserControl
{
    [Inject]
    protected ViewModel VM { get; set; }

    protected Microsoft.UI.Xaml.UserControl BuildObjectGraph() {;
         // Create object graph here for ChildComponent and it's nested Control.
    }
}

Essentially the effort needed here is the generation from razor generated AST to XAML.Direct instructions to construct the Object Graph.

[Mike-E-angelo]

To be sure, @RyoukoKonpaku, are ChildComponent and NestedComponent in NameSpace.SomeControls or Namespace ? My Razor/Blazor is rather newb, so I am trying to understand how it is resolving those.

In either case, that does look interesting and worth an exploration, IMO. 👍

[reli-msft]

I think this could be discussed in https://github.com/dotnet/csharplang? It is all about extending C# to provide ability to define embedded DSLs, then you can have a UI DSL and other DSL if you need.

[RyoukoKonpaku]

@Mike-EEE yep ChildComponent and NestedComponent are C# classes that derives from ComponentBase on the NameSpace.SomeControl namespace, I kinda flunked the example abit there but it should have referenced NameSpace.SomeControls.ChildComponent on the generated class instead of NameSpace.ChildComponent.

You can also refer the full namespace to reference a Component just like how you'd reference a normal class.

<NameSpace.SomeControls.ChildComponent>
    <NameSpace.SomeControls.NestedComponent />
</NameSpace.SomeControls.ChildComponent>

The AST to C# class is the bigger effort if this was to be done from what I can tell but it's definitely plausible with the tools available now, Xaml.Direct, Razor's AST, and knowledge on gluing those together, razor bits from the Razor compiler team and Xaml.Direct usage from the WinUI team.

[Mike-E-angelo]

You might be onto something @RyoukoKonpaku. I'm taking @reli-msft's hint and moving this onto a perhaps more pertinent forum: https://github.com/aspnet/AspNetCore/issues/10911

See you there. :)

[bschoepke]

I would push for TypeScript instead of C# personally. It would lower the barrier to entry significantly.

I would also completely kill markup; the simplicity of Swift UI is that there is only a single, expressive programming language for everything. No XML or JSON to deal with.

If we do something new, you should be able to incrementally adopt it into existing apps.

The real advancement would be to enable mixing/matching web-based and native controls in the same app or PWA.

[mdtauk]

I would push for TypeScript instead of C# personally. It would lower the barrier to entry significantly.

I would also completely kill markup; the simplicity of Swift UI is that there is only a single, expressive programming language for everything. No XML or JSON to deal with.

If we do something new, you should be able to incrementally adopt it into existing apps.

The real advancement would be to enable mixing/matching web-based and native controls in the same app or PWA.

Most UI examples I have come across involving JavaScript - still relies on markup languages like XML or HTML/CSS.

[bschoepke]

I would push for TypeScript instead of C# personally. It would lower the barrier to entry significantly. I would also completely kill markup; the simplicity of Swift UI is that there is only a single, expressive programming language for everything. No XML or JSON to deal with. If we do something new, you should be able to incrementally adopt it into existing apps. The real advancement would be to enable mixing/matching web-based and native controls in the same app or PWA.

Most UI examples I have come across involving JavaScript - still relies on markup languages like XML or HTML/CSS.

Some of the newer MSFT web frameworks are pure TypeScript (https://github.com/Microsoft/fast-dna) and we've found massive advantages to this. It's just much simpler to only deal with one, expressive programming language vs. a bunch of domain-specific languages.

Reminds me of the old Code == Data debates that LISP advocates like to make.

[mdtauk]

Some of the newer MSFT web frameworks are pure TypeScript (https://github.com/Microsoft/fast-dna) and we've found massive advantages to this. It's just much simpler to only deal with one, expressive programming language vs. a bunch of domain-specific languages.

Reminds me of the old Code == Data debates that LISP advocates like to make.

That example https://explore.fastdna.net/components/action-toggle/ Is still rendering to HTML. For that there is already Fluent Web and Fabric Web.

I am talking about rendering the same XAML UI, but possible alternatives to the Markup, which can be very verbose and imposing with its XML style syntax and "obtuse" approach to control styling.

SwiftUI uses the same Swift code syntax, but allows XAML style concepts such as property binding, and including UI within other UI that is spread across multiple files.

This is what inspired me to open this discussion. XAML has been around for almost 11 years, and since then:

• Android uses a declarative markup language, and Kotlin is their main code language.
• HTML/CSS has become more powerful with JavaScript coding.
• Apple has moved away from its XIB (XML Interface Builder) approach and moved to Swift.

Swift and Kotlin as with C# were designed to feel familiar to Java concepts, and are a lot more alike.

Are there lessons that can be learned?

[bschoepke]

Some of the newer MSFT web frameworks are pure TypeScript (https://github.com/Microsoft/fast-dna) and we've found massive advantages to this. It's just much simpler to only deal with one, expressive programming language vs. a bunch of domain-specific languages. Reminds me of the old Code == Data debates that LISP advocates like to make.

That example https://explore.fastdna.net/components/action-toggle/ Is still rendering to HTML. For that there is already Fluent Web and Fabric Web.

I am talking about rendering the same XAML UI, but possible alternatives to the Markup, which can be very verbose and imposing with its XML style syntax and "obtuse" approach to control styling.

SwiftUI uses the same Swift code syntax, but allows XAML style concepts such as property binding, and including UI within other UI that is spread across multiple files.

This is what inspired me to open this discussion. XAML has been around for almost 11 years, and since then:

• Android uses a declarative markup language, and Kotlin is their main code language.
• HTML/CSS has become more powerful with JavaScript coding.
• Apple has moved away from its XIB (XML Interface Builder) approach and moved to Swift.

Swift and Kotlin as with C# were designed to feel familiar to Java concepts, and are a lot more alike.

Are there lessons that can be learned?

We're on the same page. I think the major advancement of Swift UI is that it looks declarative but there is no markup or DSL; your app is just 100% Swift. I believe Flutter achieves the same thing via Dart.

I've been doing XAML for 10 years on multiple teams and the ramp up time is severe. Swift UI looks like it will be massively easier to start using because there are just far less concepts and DSL's to learn.

I wonder if we could just make Swift and Swift UI work on Windows via xlang and WinUI 3.0.

[michael-hawker]

From Twitter

I always find it easier to move bits & pieces of XAML around, either for prototyping or re-use, than if I have bits of code to move around, especially subsets.

Plus, it's easier to separate concerns in XAML with data binding than being tempted to smash it all together in code.

[mdtauk]

From Twitter

I always find it easier to move bits & pieces of XAML around, either for prototyping or re-use, than if I have bits of code to move around, especially subsets. Plus, it's easier to separate concerns in XAML with data binding than being tempted to smash it all together in code.

I agree that is the good part of XAML, you can just copy the markup and move it. But even if you used code or some other syntax - it would still be a separate file with a code behind.

[JaggerJo]

React, Flutter, Elm, Reason and now Swift UI (I think) all use a MVU like approach.

It would be great if there was something like this for Win UI / UWP. I don't think we need yet another language, but a solid abstraction we can agree and build DSLs on top.

[mdtauk]

These are all very similar. The C# concept of a Model is out of scope for this discussion, but we can presume that remains as is. The only change we need focus on is the View. The Controller, or Update step would be the code-behind portion of this, and so would remain as is - but the ViewModel seems like a clunky solution, purely because XAML wants to be kept separate, and each Xaml file has a code-behind that MVVM wants to avoid putting code into.

[weitzhandler]

Somehow related: https://github.com/dotnet/csharplang/issues/350#issuecomment-489240829

[ekral]

These are all very similar. The C# concept of a Model is out of scope for this discussion, but we can presume that remains as is.

I think that MPU is like a MVVM with the immutable ViewModel. The difference is that in MVVM we define the presentation model (ViewModel) containing data and UI behaviour separately from the domain model. The weak point of the MVVM is the notification of updates using the PropertyChanged event. In MPU you just create a new model instance and that is all you must do.

[Mike-E-angelo]

FWIW, SwiftUI as a Flutter application: https://medium.com/flutter-nyc/building-the-swiftui-sample-app-in-flutter-67bb4f9c571c

I am still not sold on this whole way of thinking, but consider myself subscribed to its newsletter and am interested to see how it evolves. Lots of room for improvement, IMO.

[ryandemopoulos]

This is a great (and deep) topic, and over the last few years our team has sort of danced around it with ideas here-and-there. We did some light explorations about 3 years ago at adopting a CSS-like syntax for styling. More recently we've had some internal discussions about the pros/cons of XAML as a language, and how to evolve that moving forward vs. adopting other languages/syntaxes. These sorts of "investigations" (if you want to call them that) have been mainly 1-off efforts and always done with the tacit understanding that it's pretty hard to develop and adopt new languages on existing technologies. That's not to say it can't be done--just that it has a huge downstream cost of confusion and people having to learn a new way of doing things (with a huge documentation cost to help educate folks too).

At some point I think we should look at this more holistically; I appreciate you raising this topic up @mdtauk. I could see us assigning a Program Manager from our team to this topic to take a pretty serious look at it. In keeping with what I posted in #966, I'm going to remove the Feature Proposal label and keep this as an ongoing Discussion issue--the great comments in here will serve as a solid starting point for if/when we can take a more concentrated look at it. For the time being, we're pretty heads-down on just trying to get WinUI 2.x and 3.0 planned, so this would certainly be a post-3.0 thing (and therefore spill into 2020).

Hope that makes sense. Want to keep this active--the discussion is great.

[MarkIngramUK]

I would be happy with the ability to create a ControlTemplate in code to begin with. We can already achieve creation of UI controls in code, and it might be a little more verbose compared to SwiftUI's approach, but it's still possible. I would rather give code the same ability as XAML to start.

[RyoukoKonpaku]

@Mike-EEE You guys might be interested on this recent NDC conference with Steve Sanderson (Lead dev of Blazor). He managed to do what I assumed was possible on the above discussion regarding Blazor using non HTML controls (in our case we'd want to use native WinUI controls). Here's the NDC link and it's around 54 min mark where he uses a Flutter backend + Blazor to render a fully cross platform native UI.

This might be a plausible path that WinUI can integrate with to enable full C# capability within the UI framework like JSX via React Native then slowly enable xplatform capabilities and you'll have access to Web, Mobile, and Desktop platforms.

[Mike-E-angelo]

You guys might be interested on this recent NDC conference with Steve Sanderson (Lead dev of Blazor)

I am amazed. Blamazed even (sorry, couldn't help it -- but now have the name for my next project 🤣).

If @stevesanderson / @danroth27 / Blazor leadership team doesn't productize this Blutter product idea (with a better name, of course 😉), it will easily be the worst disaster MSFT mistake since Clippy shelved Silverlight. 😆

You are basically saying you have built an idiomatic bridge to your direct competition, which allows developers to use C# rather than Dart while also (!) utilizing Visual Studio rather than whatever Flutter is using, all under the power of the Blazor API. I am not sure why you would NOT want to productize this?!?!?!

[weitzhandler]

@Mike-EEE I've watched the whole video through and looks amazing indeed. However, I'm still more a fan of sticking to non-HTML UIs we're already used to, such as XAML. BUT, it might be a great idea if we could integrate C# snippets into XAML like Razor does. If they do that, that'd be a complete game changer for XAML.

[ekral]

@Mike-EEE I've watched the whole video through and looks amazing indeed. However, I'm still more a fan of sticking to non-HTML UIs we're already used to, such as XAML. BUT, it might be a great idea if we could integrate C# snippets into XAML like Razor does. If they do that, that'd be a complete game changer for XAML.

Actually, their last demo in the video presents Blazor with the Flutter UI renderer instead of the HTML UI.

[ekral]

Personally I think that the Razor syntax for Flutter looks better then the Flutter Dart syntax or Swift UI.

[Mike-E-angelo]

Personally I think that the Razor syntax for Flutter looks better then the Flutter Dart syntax or Swift UI.

Agreed @ekral. Call me old-fashioned, but I far prefer having markup represent UI/controls than code. Conceptually, I like having a clear cognitive separation between "presentation" and "code." I don't mind Blazor's binding syntax too much, but I can see how others might have a problem with it, especially with a Xaml background.

I guess after suffering nearly a decade from a lack of true .NET client application development model, I am thirsty enough to tolerate it. 😆

[apws]

HI, somebody mentioned NeosisGUI (I traversed here from other issue related to xplat UI) and all I can say after some long reads is that it looks like silverlight native agcore.dll on steroids, having/planning almost full wpf features. Back in maybe 2006 I wished to have SL on industrial NETCF terminals, I hoped a lot, as SL is in fact, fast native engine writing directly to GPU/DX/something, I dont know, with NETCF scripting. Not having that, I made apps tageted to NETCF, using tiny subset of winforms where compiled assemblies worked on desktop for development, so I tweaked the VS tooling with some #ifdefs and lived with that, having tiny DI runtime assembly switching with pinvoked and glued things to custom device sdk and shared sqlservercompact etc... back to topic: what about best possible tooling around NeosisGUI "for now" (maybe some MS investment to these guys) ... I know its tiny and primarily targeted to games, but they made it runing everywhere, it seems ... no flames, peace, of course :) https://channel9.msdn.com/blogs/tina/Silverlight-Rehab/

[mdtauk]

XAML seems pretty contained, and rather than replacing XAML or augmenting a new Hybrid XAML - any new solution should probably exist alongside XAML, and use the same Rendering stack. A new parsing engine could be made.

CSS for styling makes sense, as it is very familiar, and may just need a doctype equivalent to mark it as WinUI.

As for the markup, or UI building documents - That will need a lot of thought...

• SwiftUI uses Swift, so for Windows, it would be non-compiled C#, VB or C++ (Maybe XLang solves this approach so you don't need to make 3, 4 etc different parsers.)

• HTML is likely too primitive and fixed in its ways.

• JSON would drive people mad, with how easy it is to malform.

  XAML has been around for over a decade, and has equivalents like XIB and AMXL to learn from. Windows is now using XAML internally for Shell code, and so there should probably a heart to heart discussion, company wide:

• Where are the pain points with XAML?

• Where does XAML exhibit quirks which are vastly different to competing frameworks/platforms?

• Where is writing UI done better?

• How do we develop a new declarative UI pattern, with flexibility for future additions, and potential support for cross platform dev, Xamarin, React, etc.

[Odonno]

@mdtauk Answering this question is really hard. I think that to fully answer this question, someone need an holistic view of every UI tools/specification available in our hands with a large spectrum in order to bring the best vision around this subject.

IMO, I believe that the Windows ecosystem needs a declarative UI language and it should target only the Windows ecosystem to do one thing and doing it right, starting with the UWP for a start, why not? Because react does a great job but for the web only (react-native does not count here), jetpack compose for Android and SwiftUI for iOS.

Before going further, I need to tell you that I know HTML/CSS/JS combo and C#/XAML combo well. I am used to angular and react these days and I am in love with react & jsx. I also did some v-dom stuff which is kind of the root of react so I have a good understand of virtual-dom and the benefits/inconveniences. That's a great start but like I said, still need to get deeper knowledge with latest UI patterns (Flutter, Jetpack, SwiftUI).

So from my perspective, I think a declarative UI language can have a clear benefits over C#/XAML:

• XAML has a good data-binding but you often have to take care of stuff in your C# code (transforming your object). But not a big deal (you have converter right?).
• Event handling makes it hard to work every day. Ok, with MVVM pattern you have commands and you can pass a parameter. But then what about passing multiple params or a big data object with everything you need. And also, you cannot make a reference to a XAML element. Compare it with a js function in angular/react and you will know :)
• And what you will expect is components... Making tiny reusable components.. Both stateless and stateful components is really making devs productive. Of course, you can use Style property on some design elements in XAML and/or create custom elements but then you will have to deal with passing props down and, you know..

That's a lot of criticism but I assure you that I have nothing against XAML. I like the way it brings the whole vision of the view in one page and it's great. But when making huge apps or having some modularity in your app, you'd like to compose the UI and XAML does not offer that.. Well, that's an argument against inheritance but I suppose that's why the libraries we are talking are a trend.

Finally, I really love the new React hooks feature and it can be a bit scary but it is really smart how they did it. It works really great in their "engine" and I suppose you could make some if you were in a React/XAML world:

• useState/useEffect = the default ones
• useTransition/useCompositionAnimation for animations
• useRouting for navigation
• and so on..

Well, to have something more concrete about this imaginary language, I started to write something some months ago and I'be honest, it takes quite some time because

• you have to make sure the default system works (in pure C#) and that basic UI controls are integrated (containers, buttons, text elements, etc..)
• you need a new language like jsx, something like XAML-like syntax in C# and so you need a parsing tool and so you need some kind of compiler for this language (that compiles into pure C#)
• testing different language specification (having a concise declarative code and being able to extend the language)

But then, you have to remember the pain point is that a XAML tree is clearly not a DOM tree, which can lead to a more longer talk. :) To be short, I managed to make a virtual XAML tree by reusing existing elements even in extreme conditions where a virtual DOM would have rewrite elements. That kinda make me think it looks like a combination of both react and imba.

To conclude, that's still a PoC and I am far from a stable project but I get it that more and more people are waiting for such a thing. We now need to figure it out.

[mdtauk]

@Odonno Xaml does have User Controls, and you can make Custom Controls - but these can be tricky to create, and use. There is a lot to be said for simplifying the Tree. Making each control or component a self contained element, which can be positioned anywhere.

[michael-hawker]

I feel like if things go down this route at all, it should be built on top of the ideas of XAML Direct and just the Native XAML code-behind instantiation. Maybe some of the improvements to C# object instantiation in general can help in tandem with this type of work.

Having worked with various code based UI frameworks in the past in various languages, the power of XAML is really the ease in which one can copy and paste things around in the XML structure without having to re-work anything. With code, there's a lot of other syntax that gets in the way when trying to move things around, especially when code is needed to direct the relations of UI elements to one another as well.

It seems like a large effort to create a new system, but if we can improve the existing systems to aid others with other UI paradigms in transitioning to leveraging XAML itself in combination, it could be useful to approach from that angle from a language and construction view in general.

[mdtauk]

@michael-hawker Bearing in mind WinUI will need to also support C/C++, VB, and possibly JS with React Native.

[michael-hawker]

@mdtauk good point, I get hyper-focused sometimes on the .NET side of things from the Toolkit.

Though I think that also shows where XAML itself can shine as it's a well understood and powerful abstraction that doesn't need to tie-itself to the language driving it. 😉