Features and documentation to increase Blazor adoption in the face of incumbent javascript frameworks such as React

[ApolonTorq]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I'm advocating for Blazor in enterprise projects due to its unified language stack applicable across web, windows, mobile, and other platforms. However, corporate inertia and front-end developer preference for open-source JavaScript frameworks, notably React, often hinder these Blazor proposals.

Technological hurdles in reusing component libraries from other ecosystems often impede Blazor adoption, despite its advantages for C# developers.

Describe the solution you'd like

Microsoft greatly enhances support for re-using open-source Javascript framework ecosystems within Blazor applications by adding features and documentation for that re-use.

A response to this feature request could be along the lines of "great idea, feel free to implement it" 😄. However, I would argue that if increased Blazor adoption is considered, then this sort of feature is arguably more important than other more technically focused features and also best considered by the core Blazor developers.

The exact nature of the enhancements is best defined by Microsoft Blazor experts but I've included some potential approaches from the perspective of a developer with admittedly basic front end skills.

Qwikify Approach

• Include a Blazor component wrapper or tooling that allows a React component to be embedded using an approach inspired by the $qwikify functionality from the Qwik framework.
• Document the caveats in terms of preference for "larger" components being embedded for performance reasons.
• Include support for wrapping, hydration control and easy access to properties/events using Blazor idioms.

Mitosis Approach

• Contribute a Blazor target to the Mitosis toolset.
• Ensure the generated Blazor component includes idiomatic support for Blazor properties/binding/events.

Web Components Approach

• Include a Blazor component wrapper or tooling that allows web components to be easily embedded or generated as a Blazor library.
• The intent would be to allow a web component library to be used in a Blazor project with support for properties/binding/events as idiomatic Blazor code without friction for the Application developer and without the need for a wrapper open source project for each web component library

Documentation Approach

Ideally, the Microsoft solution would implement a Microsoft extension library containing Blazor functionality extensions for re-using React (or other) ecosystem artifacts. However, this might not be easily organized with the broader aspnetcore product development and maintenance process. An alternative is to produce documentation and sample code which has the multiple benefits of:

• Informing developers of how to build wrapper components and/or tooling for integrating Javascript framework components and artifacts into a Blazor library. The emphasis should be on a fully wrapped result for Blazor developers rather than a myriad set of snippets that end up littering Blazor source code.
• Providing a complete but not "maintained by Microsoft" starting point for others to use in their own code or start an open source project.

I would be personally prefer that Microsoft take up the baton of simplifying external javascript component integration for Blazor developers and particularly for React. However if that request results in a "no", then a documentation based approach is better than nothing to help wear down the friction of adoption in the face of javascript framework incumbents.

Additional context

No response

[mkArtakMSFT]

Thanks for sharing this with us, @ApolonTorq.
This is interesting as it's inline to how we have been thinking about what's next for Blazor for .NET 9 timeframe. So I'll keep this on our .NET 9 candidate list to review later and see what specific work we'll extract from this.

[ApolonTorq]

Sounds good, thanks for the inclusion of the suggestions into the .NET 9 consideration process.

[danroth27]

Hi @ApolonTorq. We've been pursuing the Web Components approach, because that is based on the latest web standards.

You should be able to use any Web Component in a Blazor app as a custom HTML element, just as they can be used from any other frontend web framework. That's actually how the Blazor Fluent UI components are built. They are mostly manually authored Blazor component wrappers around the Fluent UI Web Components. Most frontend web frameworks have a way to build custom HTML elements so that they can be used with other frameworks. You can use Blazor to build your own custom HTML elements too that can be used from other frontend web frameworks.

Wrapping web components with Blazor components is currently a manual process. Do you have thoughts on how we might make this better? Maybe the community could experiment with some automated tooling for this?

Using Blazor components as custom elements in other frameworks also has some limitations:

• It's not easy to package a .NET library or a Blazor component library as an NPM package. We have a sample that shows how this can be done with React, but there are friction points that we should address.
• Blazor requires downloading a WebAssembly-based .NET runtime to run in a browser. This makes the experience heavier than just including a normal NPM package. If you add multiple .NET based libraries to a JavaScript app, you probably don't want to download multiple runtimes, so you need some way to normalize on one. These are user experiences that need to be ironed out.

[ApolonTorq]

Hi @danroth27! Note that the solution I'm asking for specifically relates to making it easier to embed Javascript framework components in Blazor applications and not the "reverse" of building custom HTML elements/components that wrap Blazor components.

I'm actually surprised that "Blazor Custom Elements" functionality was implemented first instead of its semantic inverse. I think there is far more value for Blazor adoption to instead focus on making it easy to re-use javascript components in Blazor applications. It reduces a friction point for deciding whether to write a Blazor app or a Framework X app.

By contrast, considering Blazor Custom elements instead accepts the status quo of Blazor being a bit player in these scenarios. Yes, this is somewhat provocative wording but it stems from experiencing dogmatic reactions to using anything other than React in many industry scenarios.

So the proposed solution is to make it easier, either through producing documentation or code, to write blazor wrappers such as fluentui-blazor.

An example of Documentation in this regard could be produce a summary of the mapping patterns applied in the fluentui-blazor project from javascript to Blazor. Though at first blush, it may seem "simple" in that there are commonalities in the high level concepts such as fields, properties, methods and events. My difficulty is that the evolution of both javascript and blazor is that there are wide variety of implementation patterns in both javascript and C# over time and being aware of the nuances.

Ideally, the more the wrapping process could be automated the better. I urge you to have a look at the intent of the Mitosis open source project. Their tag line is "Write components once, compile to every framework". Microsoft implementing a Blazor Mitosis target would be beneficial as an example of how to automate the creation of Blazor wrappers of javascript components. The accompanying documentation for such an effort would also be useful for the implementation of Blazor wrappers of javascript components in general.

https://mitosis.builder.io:

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 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.

[veikkoeeva]

A good use case would be to make it easy to author normal web components (with constructrable stylesheets). Then make a separate case for the code that could be .NET/C#. I am thinking things like declarative web components and invokers especially. The selling point would be keeping skills fresh as "it's only web platform" and .NET tooling.

Or if I read it right about FAST components, have an example on how to do things kind of a thing easily in Blazor.

[SteveSandersonMS]

Thanks for the ideas! We are tracking this general area in a different issue, #52819, so I'll close as a duplicate of that. We will still have this issue linked so we can refer back to it in case we want to proceed with ideas from here.