Blazor Web App template should enable server interactivity by default

[danroth27]

The default Blazor Web App template is only setup for server-side rendering. It doesn't enable any interactivity modes. The means that commonly used Blazor features, like registering UI event handlers (@onclick, @bind, etc) simply don't work and nothing will tell you why. Defaults should reflect the most common use cases. It seems reasonable to expect that most Blazor users will want some form of interactivity, so the current default creates an initial pit of failure.

Proposal:

• Enable server interactive rendering mode by default. The overhead of enabling server interactivity for what is already a server centric app seems minimal: You get the Blazor Server hub, which you might not be using. To disable the hub you simply remove the call to AddServerComponents().
• Enabling the WebAssembly rendering mode should still be optional given the complexities involved with setting up a separate project.

[itsmuntadhar]

UI event handlers (@onclick, @bind, etc) simply don't work and nothing will tell you why

Hopefully this changes in near future

maybe add an option to the template so that interactivity is enabled or not? (on by default would be prefererred)

[danroth27]

I had a discussion with @mkArtakMSFT and @javiercn about this:

• We agreed that when creating a default Blazor app with .NET 8 (no options specified) that there should be some sort of interactivity enabled, at least server interactivity
• We agreed that there should still be a way to create a Blazor app that has no interactivity enabled for folks that only want server-side rendering (SSR)
• We agreed that when you have both server and WebAssembly interactivity enabled you should get the new auto rendering mode

I think we want the default options for the template in VS and on the CLI to be the same. We have Blazor onboarding tutorials for both VS and CLI based users on the .NET website and we want both sets of users to have a good default experience.

So, the main question here is whether we also want WebAssembly interactivity and the auto rendering mode to be enabled by default in .NET 8. Enabling the WebAssembly render mode in .NET 8 will require adding a separate project for the WebAssembly content (see #49079 for the related discussion). We still aspire to get to a single project mode Blazor and WebAssembly, but not for .NET 8 due to the complexities involved. If both interactivity modes are on by default then we can flip the current options to opt-out of individual render modes. If we don't want WebAssembly enabled by default to avoid starting new users with a multi-project solution, then we'd need to make server opt-out and WebAssembly opt-in. We haven't finished implementing the WebAssembly support and auto render mode, so perhaps should wait to see what that feels like before making this call.

[haslingerm]

If both interactivity modes are on by default then we can flip the current options to opt-out of individual render modes. If we don't want WebAssembly enabled by default to avoid starting new users with a multi-project solution, then we'd need to make server opt-out and WebAssembly opt-in. We haven't finished implementing the WebAssembly support and auto render mode, so perhaps should wait to see what that feels like before making this call.

Despite being a big fan of WebAssembly and planning to make as many components as possible WebAssembly capable (being switched to by the auto mode - soon) I would recommend WebAssembly to be opt-in as long as the companion project is required.

I am teaching programming classes as well and can say that for beginners a simple project (with good defaults so the CLI command is concise) with as few moving parts as possible, that can be F5'd and tried right away, is important to get them excited and on-board.
This also means that at least server interactivity should be on by default, because static pages are a little boring for a first experience.
Btw. I once created a template that not only gave them the Counter but also a simple but playable Snake right out-of-the box which was received very well - maybe there could be a --with-fun parameter which adds such gimmicks, especially for younger students 😉

[Seanxwy]

There should be a different way of communicating than the blazor server side, not a long connection mode, just to support the need for onclick.

[Sander-Brilman]

We agreed that when creating a default Blazor app with .NET 8 (no options specified) that there should be some sort of interactivity enabled, at least server interactivity

I agree with having a default interactivity mode, the main selling point of blazor (for me atleast) is the ease-of-use with state and events like @onclick and @bind.

If we don't want WebAssembly enabled by default to avoid starting new users with a multi-project solution, then we'd need to make server opt-out and WebAssembly opt-in

I agree with the server opt-out and WebAssembly opt-in, i think its a good choice.

This because WebAssembly requires you have to work with HttpClient to get all data, that in turn requires to have an api in place. Server interactivity on the other hand is so much simpler to write. You can directly use EF core (or other data access) in the components.

Starting with a single project instead of 2 is also a benefit.

We agreed that there should still be a way to create a Blazor app that has no interactivity enabled for folks that only want server-side rendering (SSR)

I agree with that. I dont expect to use it myself but the option should be there.

We agreed that when you have both server and WebAssembly interactivity enabled you should get the new auto rendering mode

Im not sure if i agree with this, like i said before, WebAssembly requires to have to work with HttpClient and an API, With auto mode you are still using WebAssembly just not on the first load. meaning you still have to write your code as if it was with WebAssembly interactivity.

However This is only a problem for data access you can always change the render mode for data access components, and having the auto mode as default when both are selected is a great way to show what's possible.

This is something to consider, All the other proposals i agree with.

And yes, a snake game in the template would be a cool addition

[itsmuntadhar]

However This is only a problem for data access you can always change the render mode for data access components, and having the auto mode as default when both are selected is a great way to show what's possible.

which in turn would be beneficial. i.e. your page is server-side rendered but your card/table/chart/whatever component is client rendered. I can see it improving performance even if slightly

[danroth27]

This is done with #49801