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.

[ghost]

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>

` 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

[genifycom]

I really hope the XAML interface dies off. Tried it heavily in Silverlight and it should have died after that.

Please move towards a standardized approach and deprecate XAML in MAUI. Never going to use it.

Blazor is a much superior approach.

[ParadiseFallen]

In fact, we have almost everything for such a possession. there are Blazor components. All widgets in Blazor components should be expected.

Here is a great example https://learn.microsoft.com/en-us/mobile-blazor-bindings/

It is worth noting that it will be necessary to refine the attached properties and behavior. All this can be implemented through the slot.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[akhanalcs]

This sounds like such a neat idea. Would love to see it in .NET 8!

[bxjg1987]

like blazor

[akhanalcs]

Any update on this wonderful idea?

[davidfowl]

The issue is in the backlog and .NET 8 is done. This area isn’t a priority for the team.

[akhanalcs]

Thank you for the response David. Is this something the team will look into in .NET 9? I ask this because this will massively improve developer productivity, and can potentially attract developers from outside .NET community to try Blazor, MAUI and so on.

[davidfowl]

I don’t know but I’d say it’s unlikely. I could be wrong but I don’t think this is “the thing” that will make Blazor appeal to the masses. As much as I love the idea of a code based model, it unclear that this level of investment would pay off.

That said, if a group of people think this is the missing piece of the blazor puzzle, I’d encourage you to work together on coming up with what a concrete proposal would look like.

[akhanalcs]

My motivation for this is more about MAUI than it is about Blazor. If MSFT will bring Blazor's Razor syntax to MAUI, I couldn't care less about this.

Blazor's Razor syntax is already pretty amazing for .NET developers (I love it!) but for developers coming from other programming languages like Swift, Flutter etc. this will be very nice (as they don't even have to learn Razor, just C# would suffice) but for MAUI development, this will be a game changer.

Also see this.

[saint4eva]

... other programming languages like Swift, Flutter etc. this will be very nice (as they don't even have to learn Razor, just C# would suffice) but for MAUI development, this will be a game changer.

Maybe you can try Comet C# MVU - it is a .NET Maui library for developing apps using C# only. It has great binding and grid system and it makes developing apps easier. Comet or you can try ReactorUI

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[MichaelSong9]

like blazor

[rf-0]

Interesting frameworks (MVUs) but unlikely to be accepted/approved by big enterprises (learning curve/dependencies/risk).

XAML is legacy and I've ended up here because, like everyone else, I have been looking for a way out. In my opinion the right approach (investment) by MSFT is to go with a unified syntax (razor - blazor is widely successful) as mentioned above. This would improve mobile and web app development velocity by orders of magnitude, especially for the enterprise, whilst at the same time making everyone happy. Mobile Blazor Bindings FTW!

[saint4eva]

MVU pattern is more simple and easier to learn compare to anything mvvm or xaml could offer.