Provide a pure code model for creating and working with Blazor components

Blazor components today are typically authored using Razor syntax, which is designed to make it convenient to define dynamic HTML rendering logic using a combination of HTML and C#. You can define Blazor components directly in C# code, but then you’re working directly with the RenderTreeBuilder which is more designed as a compiler target than a user-friendly API. While it’s not super common to build Blazor components directly in code, it is done (we build that built-in Blazor components this way) and the user experience could be substantially improved.

There may also be an opportunity here to reuse this work to help .NET MAUI. .NET MAUI is exploring providing a programming model that is not XAML based in order to appeal to a broader developer audience. Comet was built as one potential approach. We also explored in the Mobile Blazor Bindings (MBB) experimental project using Razor syntax and Blazor components to work with native UI as an alternative to XAML. While this model potentially appeals to existing Blazor users, using Razor markup syntax for native components arguably has limited value in that there is no inherent markup language for native components. We’re effectively inventing another one (like XAML).

If we had a pure code model for working with Blazor components we could potentially still use the work from the Mobile Blazor Bindings to wrap native component and then use the Blazor component model to compose native UI without the need for markup at all. This approach may appeal to existing Flutter and Swift UI developers that are used to building UI with a fluent style programming model.

[meisam-dehghan]

I think It’d be great for .net developers to be able to develop both web and native applications with one unified language(Razor syntax). In fact, the reason that .Net Maui hasn’t lived up to the expectations of many developers somehow has to do with XMAL, which is pretty hard to work with. The way binding works in XAML has a lot to be desired for since it’s string-based and most often you would have no idea whether the binding works or not until the app runs! However,Razor is a great syntax to define the UI with in both web and native apps (Blazor Mobile Bindings).I’d love to be able to bind properties of controls in a .Net Maui app like in Blazor.The way binding works in a Blazor application or any Asp.net core app with Razor syntax is a whole lot better than bindings in XAML. I think Blazor is the future,and why not provide the same model for native applications? I think thousands of web developers using Asp.net core would be encouraged to get involved with mobile developments as well if they could create a mobile app with the Razor syntax that they are already familiar with. Just take a look at the way this command in the DataTemplate of a CollectionView needs to be bound: First of all,you need to set a ViewModel as the BindiningContext and define a command (MarkAsReadSwipeCommand, in this case) , but even then the IntelliSense wouldn’t pick it up! You have to enter the Path to the command as a string! Looks pretty complex,huh? To make it worse,If you made a typo, you would have no idea of the error until the app runs! Even if you define the DataType at the top of the page,the mistakes with complex bindings wouldn’t be caught before runtime! <SwipeView.LeftItems> <SwipeItems Mode="Reveal"> <SwipeItem Text="Read" Command="{Binding Path=BindingContext.MarkAsReadSwipeCommand, Source={x:Reference Name=ThisPage}}" CommandParameter="{Binding .}" BackgroundColor="{StaticResource MainColor}"/> </SwipeItems> </SwipeView.LeftItems> So,All in all,Blazor has taken the web development world by storm since it was intruduced. Just go the same path and provide the already-popular pattern for native development as well.I have experience with developing xaml-based application dating back to Silverlight and I’d tell you from my experience that Microsoft should invest in Mobile Blazor Bindings as the future of native development,while at the same time,you could keep XAML as an option for those having developed Xamarin apps and would like to stick with that technology.

[wubalubadubdub55]

I love this idea!