Blazor has gotten progressively less approachable since .NET 7

[matt-goldman]

I want to start by saying that I appreciate the work that has gone into evolving Blazor. The framework has introduced a number of powerful new capabilities, especially with render modes in .NET 8 and further refinements in .NET 9. However, I believe that Blazor has been moving away from one of its core strengths: simplicity.

Since .NET 7, Blazor seems to be heading in a more complex direction, largely due to architectural changes introduced to support new render modes. While these features are valuable for certain advanced scenarios, my concern is that they have led to a reworking of how Blazor is structured, making tasks that were previously simple unnecessarily difficult.

Choosing between WASM and Server used to be a straightforward choice you would make based on the needs of your app. Now, the template names obfuscate this choice, as well as introducing additional restrictions and inconsistencies. Options that used to be available across all templates are tied to specific render modes, leaving developers to manually re-implement functionality that was once universal.

I suspect that the majority of Blazor users don’t need render modes. They need either WASM or server, and that used to be straightforward. Now, the entire template system and authentication model have been refactored to accommodate a smaller percentage of users, making it harder for the majority to build and deploy Blazor applications.

Some key concerns:

• Authentication has become unnecessarily complex. Previously, Blazor had a relatively straightforward way to handle auth, but now, because of render modes, the process feels more convoluted.
• The default templates have been restructured in a way that forces developers to deal with complexity they may not need. Instead of simply documenting how to enable advanced scenarios, the entire framework has shifted to accommodate them by default.
• Blazor’s core value proposition - making it easy for .NET developers to build front-end applications - feels less prominent in recent releases. What used to be a simple alternative to JavaScript-heavy front-end frameworks now requires arcane knowledge to implement things that were previously straightforward.

I’m not arguing that features like render modes shouldn’t exist, I recognise their utility for specific use cases. However, I do believe that they should be opt-in, rather than the default structure that dictates how all Blazor projects are now built, especially given the impact they have on everything else.

If the goal is to make Blazor more powerful, that’s great; but shouldn’t that come as an option for those who need it, rather than forcing that complexity onto everyone?

Most of us just want to build web apps, and one of Blazor’s biggest strengths was how easy it made that. Now, instead of focusing on building great applications, we have to navigate added complexity and specialised knowledge that’s only relevant for a small subset of use cases.

I’d love to hear from other Blazor developers on this. Do you feel that Blazor has become unnecessarily complex? Would reverting to something closer to the .NET 7 templates (with the option to enable advanced features when needed) be beneficial for the majority?

Looking forward to hearing others’ thoughts! And absolutely keen to be put in my place if I'm in the minority.

[VladislavAntonyuk]

as for me, unless I choose Auto mode, Blazor Server Mode is awesome. It is simple. I see a layout, I see components. I know where my files should live. Auth also doesn't look complex if you don't use Individual Accounts with a ton of pages.

But back to Auto mode. 2 projects are more complex than 1. I see the same folders in both projects, I get confused about what file should I put in which project. Where I should add attributes for render mode and where I put my wwwroot and appsettings.json? How to pass auth and ensure my project is safe. I get an issue with Injecting services in constructor in Client project (only Inject attribute works), while it works in the main project.

I haven't used a Blazor WebAssembly a lot (only my website uses it: https://vladislavantonyuk.github.io/), mostly Blazor ServerSide rendering, maybe that is why I ask such questions.

[javiercn]

@matt-goldman thanks for contacting us

We appreciate the feedback and some of it is fair. In general, Blazor has expanded its reach to support additional scenarios and more choice, and unfortunately that flexibility can't come for free.

That said, the previous options are still there and can be perfectly used:

• Blazor Server is Blazor Web + Interactive Server Components + Global Interactivity
• Hosted Webassembly (+prerendering) is Blazor Web + Interactive Wasm Components + Global interactivity
  • The main change here is prerendering by default on the server, which adds the complexity that you need to handle running on two different environments.

Beyond this, there are new options that you are completely "free" to ignore in your app.

• If you don't want enhanced nav, don't use it.
• If you don't want to support SSR (forms, etc.) you don't have to.

You can stick to the two combinations above and get the same experience that you had in the past. No need to worry about render-modes, enhanced nav, or other features like that.

Perhaps the templates here do a disservice to the product as they shove in your face all these combinations and you can't really differentiate between them unless you have some background context.

Would a different way of presenting the templates help here?

• If we were to have a Blazor Server option that just creates Blazor Web + Interactive Server Components + Global Interactivity and Hosted Webassembly that created Blazor Web + Interactive Wasm Components + Global interactivity and disabled prerendering.

Authentication has become unnecessarily complex. Previously, Blazor had a relatively straightforward way to handle auth, but now, because of render modes, the process feels more convoluted.

What aspects do you find complex? Can you make a list of concrete things?

The default templates have been restructured in a way that forces developers to deal with complexity they may not need. Instead of simply documenting how to enable advanced scenarios, the entire framework has shifted to accommodate them by default.

Can you elaborate a bit more here on concrete aspects of where you think things have become more complex?

• I'll add one, which is, wasm prerendering requires you to ensure your app/components can run on the server in addition to wasm.

Blazor’s core value proposition - making it easy for .NET developers to build front-end applications - feels less prominent in recent releases. What used to be a simple alternative to JavaScript-heavy front-end frameworks now requires arcane knowledge to implement things that were previously straightforward.

• Can you be concrete about the things that you believe are problematic? Are you forced to use them in any way in the app or can you simple not use them?

We'd like to get more details on concrete aspects that you think are problematic and why do you think so.

[matt-goldman]

Hi @javiercn, thanks for the thoughtful response! I'll reply to your questions, but I want to clarify that while I'm happy to share my opinions, my main goal here is to gauge what the broader community thinks. I've heard similar feedback from others, which is what prompted me to raise this issue, but I fully recognise that this might not reflect the wider Blazor community.

My intention is to see whether others share this perspective—if I'm in the minority, I’ll happily accept that. As you’ve noted, none of the things I’ve raised are showstoppers; this is more about making new Blazor projects feel more seamless and approachable.

Perhaps the templates here do a disservice to the product as they shove in your face all these combinations and you can't really differentiate between them unless you have some background context.

This is fundamentally what I’m getting at. I love Blazor, and I only really use other web UI frameworks when clients specifically require it. My concerns are really focused on the templates and how they present Blazor’s options. Maybe I should have clarified that more in the original post.

Would a different way of presenting the templates help here?

• If we were to have a Blazor Server option that just creates Blazor Web + Interactive Server Components + Global Interactivity and Hosted Webassembly that created Blazor Web + Interactive Wasm Components + Global interactivity and disabled prerendering.

Yes, I think this would go a long way toward simplifying things and making Blazor more approachable. I’d love to see this. It feels like the complexity is introduced too early in the process, and this would help reduce that.

Authentication has become unnecessarily complex. Previously, Blazor had a relatively straightforward way to handle auth, but now, because of render modes, the process feels more convoluted.

What aspects do you find complex? Can you make a list of concrete things?

A few things stand out:

• The different auth options depending on the template make it trickier. For example, many enterprise apps need Entra ID authentication, and I believe this should be included in the templates (all templates). I know Add Microsoft Identity Platform auth option to the Blazor Web App template #51202 is open to bring Entra ID to the Blazor Web App template, and yes, you can add it yourself, but auth is already a challenging topic for many people.

• The inconsistency in auth options across templates can be confusing, especially for people new to Blazor. Templates often give the impression that they reflect what's supported, not just what's included. Even if someone knows they can implement it manually, they might not want to tackle something that used to be built-in.

• The simplicity of CascadingAuthenticationState and RemoteAuthenticatorView was a huge attraction for me. Now, there’s more to consider with serialization, even if you don’t need it. You have to understand all the options to set things up correctly, which feels like a higher barrier.

• Pre-scaffolding all identity pages when choosing individual accounts feels overwhelming to me, but that might just be personal preference.

That said, I really like the new IDownstreamApi approach. It’s a neat addition, and I can see how it impacts at least one of these.

The default templates have been restructured in a way that forces developers to deal with complexity they may not need. Instead of simply documenting how to enable advanced scenarios, the entire framework has shifted to accommodate them by default.

Can you elaborate a bit more here on concrete aspects of where you think things have become more complex?

• I'll add one, which is, wasm prerendering requires you to ensure your app/components can run on the server in addition to wasm.

In addition to the auth-related choices, the need to choose interactivity modes upfront adds unnecessary confusion for most use cases. I’ve mentioned this a few times, but I don’t have data to back it up—perhaps you do? I could be wrong, but I suspect the majority of users don’t need these options upfront.

The naming of templates also adds to the confusion. For example, “Blazor Web App” sounds like the default choice, but it's not immediately clear how it differs from other templates unless you already understand how render modes work. I’d expect the choice to be as simple as: Do you want this to run on the server or in the browser? I know you can achieve that, but only if you already know how to navigate the options. That understanding should come when needed, not as a prerequisite for getting started.

Blazor’s core value proposition - making it easy for .NET developers to build front-end applications - feels less prominent in recent releases. What used to be a simple alternative to JavaScript-heavy front-end frameworks now requires arcane knowledge to implement things that were previously straightforward.

• Can you be concrete about the things that you believe are problematic? Are you forced to use them in any way in the app or can you simple not use them?

We'd like to get more details on concrete aspects that you think are problematic and why do you think so.

This is really a summary of the points above rather than an additional issue. With .NET 7, it felt simple: two templates that worked largely the same, with the key difference being whether the app ran in the browser or on the server. I’d love to see a return to that simplicity.

But again, this is really a question for the community. I’m not trying to influence Blazor’s direction based on my opinion alone, I want to see if others feel the same way. If not, then there’s no reason to change course, and I’m happy to accept that.

[eric-king]

Hosted Webassembly that created Blazor Web + Interactive Wasm Components + Global interactivity and disabled prerendering.

That is the template I want (back). I would also like options that provide all the Auth bits for Entra and Identity

[hades200082]

For me, I think interactive auto is the future but only if it can be truly automatic

If I have to write code specifically for both then it's not automatic.

[begerard]

The new functionalities have caused regressions for your previous audience.

1. New modes have made creating new projects harder. The auto mode is a bad thing in most cases (it's only about helping a bit in some niche case, really), but you can't know it if you don't go read a doc witch you don't have a link to. That's 2 consecutive mistakes here from my point of view.
2. There is nothing in the templates that help to integrate any actively developped CSS framework. Bootstrap is great but it is stall, and very limited compared to other frameworks. Even your FluentUI is nowhere to be found!
3. There is no templates for the different use cases your are trying to solve with Blazor. Like, I don't even know if you have main use cases you want to support better than other frameworks. Is it the LoB your priority target, or is it simple commercial website? Maybe streaming website to concurrence Youtube/Netflix? I feel that by trying to be able to be "compatible" with as most use cases as you can, the most evident one (internal LoB app I'd guess) is harder to make instead of easier to with time passing.
4. You don't promote enough your components in the template (nor the docs). QuickGrid is great, but if you compare how you present it, and how other vendors present their DataGrid, it is not good. No realistic dataset to play with, no multiple edit mode, no excel export/filter... These are functionalities that can be demonstrated with a bit of work on your template and usage of component frameworks (FAST would do).
5. Hot reload is not usable. Full reload is slow. Debugging is sluggish. That's not great, right? Unfortunately, it's not the number 1 priority.

In the end I really feels you are throwing most of your workforce at hard technical subjects (auto mode in the past, now multi-threading and AoT) and nearly nothing to easing out the usually cases Blazor was made for. Several vendors have made great suite of components but they all have drawback (performance, time to setup, limitation in their trial...), and I think you need to take the space they left out :

1. The default experience when Visual Studio is just installed (preinstalled templates)
2. The performance when you just want to display too much things (but that's the client requirements, so...)
3. The performance when you just want to deserialize too much things (System.Text.Json in Blazor is very slow to deserialize big or complex payload, and example with an alternative serializer like MemoryPack could help).

I'm ready to give you (MS employees) access to under performing (both for the inner dev loop side and the performance side) LoB apps if you don't have enough examples, but yeah, things aren't going in the right direction for us, like Matt said.

[hades200082]

I've been quite vocal over the last couple of years about what I feel are some of the shortcomings of Blazor but have never been able to explain it very well.

Today I found this video that really captures all of the issues I see with Blazor currently and explains them very simply and I think it's relevant here too.

https://www.youtube.com/watch?v=xsy-B-cHskI

[javiercn]

@matt-goldman thanks for the additional details.

I think it's fair to say that things have gotten more complex, as we add more things it's almost inevitable that with more choice comes more complexity. I think this is not exclusive to Blazor, as other frameworks have experienced the same type of problems when they added SSR. That said, as we rationalize things, we'll identify things that we can simplify. It's a tick-tock cycle, sort of speak.

I've filed #60311 to track potential templates improvements. I've also filed #60312 to track improvements to making writing code that works across different environments easier. However, I would not consider per-page interactivity or SSR advanced scenarios, quite the opposite, is where your app should start (in the general case). Any other scenario (Interactive Server/WebAssembly) adds additional constraints to your app (persistent connection, initial download time) that might be acceptable in certain scenarios, but represent a significant trade-off in others. This is why the app default version is SSR and per-page interactivity. Alex Rusell summarizes it well https://infrequently.org/2024/11/if-not-react-then-what/#vignettes. All this is to say that the old models offered improved productivity for developers at the cost of sacrificing UX for users by requiring a persistent connection or accepting an increased startup time. It might be ok for certain types of apps, but it's not the first option to pick in the general case if you care about your users (having other options available). Blazor is meant to allow you to author all types of apps, so it needs to make choices that work for the widest range of users.

The inconsistency in auth options across templates can be confusing, especially for people new to Blazor. Templates often give the impression that they reflect what's supported, not just what's included. Even if someone knows they can implement it manually, they might not want to tackle something that used to be built-in.

The main difference here as far as I understand is the lack of Entra support, which is planned. In general we are moving away from putting this code in the templates and enabling this choice to be made after the app has been created. It's a challenge when people create the template with the wrong auth option and is a huge source for complexity to put all these options within a single template.

Pre-scaffolding all identity pages when choosing individual accounts feels overwhelming to me, but that might just be personal preference.

#60310

The simplicity of CascadingAuthenticationState and RemoteAuthenticatorView was a huge attraction for me. Now, there’s more to consider with serialization, even if you don’t need it. You have to understand all the options to set things up correctly, which feels like a higher barrier.

This is relevant only for per-page interactivity, aside from the fact that Blazor web allows you to put this in the statically rendered part of the app (which wasn't possible with _Host.cshtml, but the problem of transferring state to an interactive component existed there too)

There is an issue that I filed for it #51969 but hasn't gotten any traction.

With all that said, I am going to close the issue, as we have several issues tracking the specific improvements. We appreciate the feedback and we'll use the other issues to track specific improvements, however, general issues like this quickly become a dumping ground of unrelated feature requests and that makes things much harder for us to take action on as opposed to the concrete issues. If there's any issue that I haven't captured, please feel free to open a separate issue so that we can track support specifically for it.

[javiercn]

@begerard we would suggest you file separate issues for that. Otherwise, it makes it hard for us to prioritize specific changes.

There is nothing in the templates that help to integrate any actively developped CSS framework. Bootstrap is great but it is stall, and very limited compared to other frameworks. Even your FluentUI is nowhere to be found!

We have #53142 to track a future template refresh, that said, there's plenty of choice in the community for all forms and shapes of CSS frameworks and Fluent UI has its own package with its own set of templates.

You don't promote enough your components in the template (nor the docs). QuickGrid is great, but if you compare how you present it, and how other vendors present their DataGrid, it is not good. No realistic dataset to play with, no multiple edit mode, no excel export/filter... These are functionalities that can be demonstrated with a bit of work on your template and usage of component frameworks (FAST would do).

Templates are a starting point, not a showroom. Putting everything on the templates adds a high maintenance cost and makes everybody delete a bunch of boilerplate every time and makes it more confusing for newcomers. There's a dedicated page for quickgrid samples https://aspnet.github.io/quickgridsamples/

Hot reload is not usable. Full reload is slow. Debugging is sluggish. That's not great, right? Unfortunately, it's not the number 1 priority.

Improving hot reload is something that several teams are working on. Unfortunately, it's not something where we from the runtime bits can have a lot of effect on, since for the most part is a tooling feature.

In the end I really feels you are throwing most of your workforce at hard technical subjects (auto mode in the past, now multi-threading and AoT)

We aren't working on multi-threading as we discussed in the community standup and AoT has been a feature since the initial Blazor releases, there's no significant active development on it in the current milestone.

There is no templates for the different use cases your are trying to solve with Blazor. Like, I don't even know if you have main use cases you want to support better than other frameworks. Is it the LoB your priority target, or is it simple commercial website? Maybe streaming website to concurrence Youtube/Netflix? I feel that by trying to be able to be "compatible" with as most use cases as you can, the most evident one (internal LoB app I'd guess) is harder to make instead of easier to with time passing.

Blazor goal is to be a general-purpose web development framework and as such requires supporting a wide range of scenarios. There is an impedance in the way those scenarios are represented and the options offered in the templates. Unfortunately, with the current templating infrastructure is really hard to present things in a different way, and even if we could, I think it would be wrong to put specific "categories" in different "feature set buckets" as the decision should not be made based on the category of the app but on the specific requirements you have for your users. (Support for transient connectivity / disconnection, startup time, number of users, etc).

With all that said, #60311 tracks potential improvements in this area.

[ADefWebserver]

• If we were to have a Blazor Server option that just creates Blazor Web + Interactive Server Components + Global Interactivity and Hosted Webassembly that created Blazor Web + Interactive Wasm Components + Global interactivity and disabled prerendering.

Yes.

Thank You

[begerard]

There's a dedicated page for quickgrid samples https://aspnet.github.io/quickgridsamples/

Is there a way to contribute to this showcase and its visibility? Is there an issue discussing its development?

Improving hot reload is something that several teams are working on. Unfortunately, it's not something where we from the runtime bits can have a lot of effect on, since for the most part is a tooling feature.

Yes it's more a VS thing so I should not complaining about it here, sorry :)

We aren't working on multi-threading as we discussed in the community standup

Ok, I wasn't aware of that, the issues about it are still in .Net10 Planning last time I checked so I thought your team were prototyping about that. Looks difficult to find a good solution!

I think it would be wrong to put specific "categories" in different "feature set buckets" as the decision should not be made based on the category of the app but on the specific requirements you have for your users.

Giving advice on the solution (SSR/Progressive/Interactive/SPA) to use by categorizing apps is what the (quite interesting) blog post you linked does, and I think it would be great to have it in some form in the documentation (maybe through a link to a post in the .Net blog). It's an easy choice to do, and you can't fix a bad choice on that easily even if you always use Blazor components in the end.

That said, Blazor is a great framework and I'm a happy Blazor developer since .Net5 despite some pain points, so thank you :)

[matt-goldman]

Hi @javiercn, thanks again for your thoughtful response. It’s great to see you giving this proper consideration.

general issues like this quickly become a dumping ground of unrelated feature requests and that makes things much harder for us to take action on as opposed to the concrete issues

💯, you can already see that happening here. That said:

[I] would not consider per-page interactivity or SSR advanced scenarios, quite the opposite, is where your app should start (in the general case)

This is really at the heart of the issue for me. While I see where you’re coming from, I respectfully disagree. Blazor is a tool for building software more than it is for building websites. And with that comes an understanding that initial load times or maintaining a persistent server connection are acceptable trade-offs for many scenarios.

I’d also wager that Blazor is primarily used for enterprise apps (though not exclusively, I have consumer-facing apps built with Blazor as well). In those enterprise contexts, there’s often more tolerance for these trade-offs.

While I get that SSR and per-page interactivity provide significant UX improvements, I don’t believe the majority of developers prioritise those improvements enough to justify the added complexity being the default. At least, not with the current trade-offs.

As you said in your first response:

that flexibility can't come for free

And as @hades200082 mentioned:

For me, I think interactive auto is the future, but only if it can be truly automatic.

If I have to write code specifically for both then it's not automatic.

Until that complexity can be abstracted away for the developer, I don’t believe it should be the default.

I recognise that this is all my opinion, and I see that in at least this one area, it differs from yours. Ultimately, it’s up to you and the team to decide the future of Blazor, but I hope that in scenarios like this, you’re open to taking on board the broader community perspective. I also hope there’s a robust way to measure this sentiment; it’s understandably difficult to gauge the broader community’s perspective through individual issues like this, especially given the volume of open issues (currently around 3.5k). Maybe community surveys or targeted feedback sessions could help in gathering insights on topics like this?

While my perspective is based on my own experience, it’s also informed by conversations I’ve had with other developers. I’ve spoken to many people who are interested in Blazor but don’t know how to get started. The engineering behind Blazor is phenomenal, but I think it’s critical to maintain sight of its core value proposition: providing a simple way for .NET developers to build interactive UIs. When seasoned .NET engineers are saying “it’s easier for me to use Angular or React” (see Episode 35 of my podcast for reference), that to me seems like a potential problem with approachability.

With all that said, I can see from the issues you’ve filed that you’re taking this seriously, and I believe #60311 in particular will have a huge positive impact. So once again, thank you for engaging with this feedback, and I hope this conversation has been helpful!

[dotnet-policy-service]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.