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

[danroth27]

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.

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[wubalubadubdub55]

I love this idea!

[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.

[le-nn]

Blazor is much simpler and more productive than XAML.
I used to develop with WPF and XAML, but once I knew React and Flutter, I found XAML very annoying.

I think C# and .NET are very good ecosystems.

My team chose Flutter because XAML is difficult and unproductive, but I haven't given up on developing apps in C# yet.
I believe Blazor is the future of native app development.

[En3Tho]

I wonder what are technical difficulties here.

One that I know is assigning sequence numbers when adding markup or elements. When I did similar code-first wrapper in F# I've found no true reliable way to do this. It's hard to compete with proper compiler after all.

Other thing is that Razor compiler can infer what is markup and what is not and optimize huge markup blocks in one go. Not sure how to do this with code approach unless doing manually.

What are the others?

[danroth27]

For comparison, the .NET MAUI Community Toolkit introduced what they call C# Markup as "a set of fluent helper methods and classes designed to simplify the process of building declarative .NET Multi-platform App UI (.NET MAUI) user interfaces in code".

[ziaulhasanhamim]

It would be life saving thing. Neither razor nor XAML is as pleasant to write as C#

[saint4eva]

For comparison, the .NET MAUI Community Toolkit introduced what they call C# Markup as "a set of fluent helper methods and classes designed to simplify the process of building declarative .NET Multi-platform App UI (.NET MAUI) user interfaces in code".

C# Markup is great. But it uses mvvm app model. But for MVU C# app model, Comet is amazingly excellent. It is very simple and powerful

[VincentH-Net]

@danroth27 thanks for proposing to invest in the developer experience of C# UI👍

I've been championing and contributing to improve the developer experience for C# UI for .NET UI frameworks for many years - perhaps we can work together on this for Blazor?

Background:

I'm the author of above mentioned C# Markup 1 (which I contributed to Xamarin Forms and later to Xamarin.CommunityToolkit.Markup, which is now ported to CommunityToolkit.Maui.Markup)

I'm also author of next-gen C# Markup 2, currently for Windows App SDK, Uno Platform and WPF.

In this recent poll devs voted for MAUI to be added next:

Note that Blazor was an option added in the poll replies and my followers are mostly cross-platform native, so results for Blazor are probably not representative for the community of (potential) Blazor users.

C# Markup 2 for Blazor has tentatively been on my roadmap for a while, I did some research on how to implement that.

I'd be happy to have a conversation about this - lmk thx