Proposal: Support Razor/Blazor-like Syntax

[dotMorten]

Proposal: Evolve XAML Syntax to also support a more Razor/Blazor-like syntax

Summary

I saw @jeromelaban today show an experiment with using Blazor-like syntax for XAML, and I think this would be a good evolution of XAML:

Rationale

I've for a long time thought that XAML needed to evolve more beyond it's initial incarnation from WPF, and make xaml more succinct and efficient to write. We've seen this happen with ASP.NET which is almost not recognizable today compared to where it started, with much much less markup and code needed to create great UIs.

I think this flavor has several benefits:

• First it's still very much XAML-like reusing the same tags, and simplifying bindings.

• It removes the need for code-behind for UI specific code, and drives you towards better separation between UI code-behind and VM/Model code. The current model drives people to add too much in code-behind, beyond just view-specific code.

• The syntax will be very familiar to those already using ASP.NET MVC / Blazor.

• Way more succinct

This article is a pretty good take on why it's time for XAML to evolve (note it has now been 14 15 16 years): https://paulstovell.com/six-years-of-wpf/

[robloo]

It was really cool to see that on the call today. @jeromelaban and the nventive team are invaluable to the future of XAML and cross-platform. I'm continuously astounded by what they are cooking up.

[panoukos41]

I think this would be the way to go in the future, i love xaml from the day i tried it and after xaml a lot of things like xml/html gave me a more quirky feeling but after blazor i do find myself troubled looking at xaml ^^

[deivid77]

Please, do it!!

[robloo]

I'm usually a bit apprehensive about new XAML syntax/dialects. This is largely because every time there is a new 'latest-and-greatest' tech we seem to loose capabilities that were in the original WPF XAML (it took a long time for UWP to get where it is today, Silverlight is a sadder story, Xamarin Forms... I don't want to talk about that).

This proposal is a best of both worlds though. It's modern and simplifies code yet retains the full capabilities we have in XAML today while opening the door for new ones. I wouldn't mind porting existing XAML to this syntax at all.

[marb2000]

Thanks for opening this proposal @dotMorten, as a former ASP.NET MVP. I do love Razor syntax :)

[rajeshjha96]

This syntax will really welcome new devs to try out Windows development using XAML. It is short and sweet.

[andreinitescu]

It removes the need for code-behind for UI specific code, and drives you towards better separation between UI code-behind and VM/Model code. The current model drives people to add too much in code-behind, beyond just view-specific code.

@dotMorten You mention an important aspect, but your example doesn't show the part with "too much code-behind".
In my experience the code behind is necessary only to cover specific lack of MVVM support in the controls. So the actual problem is else where. Even with in the current state, a good way to handle this is by some reusable behaviors so you don't actually have to write that code-behind in every screen.

The XAML definitely must keep evolving and at a faster pace. In the same time, there are important decisions to be made regarding how exactly it evolves. Too much "evolving" could make it something else. If the decision will be that a radical evolving must take place, maybe the option to converge to the ASP.NET MVC/Blazor-like style is better in my opinion.

Obviously such decisions are not a walk in the park. I'm sure the actual XAML architects at Microsoft have a very comprehensive view of the shortcomings of XAML which surfaced in 15 years since XAML was launched. I'd love to hear their thoughts, maybe here maybe somwhere else...

[Banyc]

Any update on this proposal?

[AmirImam]

This will be amazing. You can find something like this in MBB, but this project has been delayed

[TheOnlyBeardedBeast]

I saw an article for something similar https://matteo.tech.blog/2020/10/26/template-based-code-generation-with-razor-and-roslyn/

[S0Eric]

I think this is a great idea but isn't there a big issue with how XAML data binding works and how Blazor re-renders on updates.

I'm not an expert of how XAML works with all UI frameworks, but my understanding is the ViewModel implements INotifyPropertyChanged so the framework knows what to update when a data-bound property changes. I'm sure it's a complex story, but I'd assume Blazor has a completely different approach to rendering updates: https://docs.microsoft.com/en-us/aspnet/core/blazor/components/rendering?view=aspnetcore-6.0

Blazor Hybrid in MAUI, where the C# runs natively and communicates with the UI through a local interop channel should probably have a different rendering story.

I've been away from .NET UI's for a while and so I recently spent many hours seeing where things stand. My recent UI experience was with a small JS framework called SolidJS (https://www.solidjs.com/). I absolutely loved the experience using it to add a component to an existing web application. It was so easy to write a component that grew linearly as features were added. From "Hello World", to "Counter", to a fairly complex component is a smooth path. You create a state object and the component is simply a function that generates the UI from that state. It supports JSX syntax that mixes markup with code, very similar to Blazor.

SolidJS has a very interesting story for efficient updates. When the UI is initially rendered, SolidJS automatically tracks which state properties are read, and subscribes to change notifications for those properties. If one of those properties changes, the UI is updated. Let's say you set a control's background color by calling a function that examines one or more state properties to determine the color (<Button BackgroundColor={getBtnColor()}...>). When any of those properties changes, instead of re-rendering the control, it just calls the function again to obtain the new color and updates the control's background color property directly. And of course it has to re-do its change notification tracking for that control property because each time it calls the function to get the background color, it might go down a different path and read different properties (getBtnColor () => state.isInProgress || state.hadError ? "Red" : "Blue").

My company is looking at new technologies for re-writing our desktop app, and I'm very disappointed that I don't see anything in the .NET world that has all these attributes:

1. XAML as markup with powerful desktop UI library.
2. Support binding to data with code expressions, from simple references to state properties to function calls.
3. Local code right next to the markup.
4. Doesn't require MVVM with all the boilerplate code for change notification.

[robloo]

@S0Eric

As far as I understand this proposal, it is only adopting the "Blazor" style syntax. WinUI rendering, layout and update system will work exactly the same. In fact the code-behind and XAML is really exactly the same too -- just the new syntax allows them to be integrated together in the same source file.

My company is looking at new technologies for re-writing our desktop app, and I'm very disappointed that I don't see anything in the .NET world that has all these attributes:

Take a look at Avalonia (http://avaloniaui.net/). The next release planned for this year is what we have all been requesting from Microsoft for years. Also look at the declarative syntax (https://github.com/AvaloniaUI/Avalonia.Markup.Declarative), you can find various projects that do almost everything you are looking for, although some may not be production ready.

[xcaptain]

I'm also very confused why Microsoft uses razor to render html pages and xaml to render maui pages. I think if someday razor and xaml get unified, more people will come to use .net in their projects.

[a44281071]

This is a perfect ideal, and it's a chance for Client developer:

• XAML developer community is gradually shrinking, most people have turned to the web camp.
• Web community is Loose but bursting with new life, we can take draw essence from it.
• Web dev toolkit is fashion-conscious, and game dev toolkit is same, But native-client dev is Slow and laborious.
• Native-client dev can use WEB ideas. But do not host a web engine(browser). Because it proves that client-dev is go downhill.

So do I:

I'm also very confused why Microsoft uses razor to render html pages and xaml to render maui pages. I think if someday razor and xaml get unified, more people will come to use .net in their projects.

[akhanalcs]

Any update on this wonderful idea?

[LuohuaRain]

Any update on this marvelous idea?

[MattBDev]

I can't believe I just saw this feature request. This would remove a huge barrier for people just learning how to make a Windows app or use XAML. I hope this is being considered for the future.