Full stack web UI with Blazor

[danroth27]

In ASP.NET Core today, we have a couple of different ways to build web UI:

1. MVC & Razor Pages: These frameworks use server-side rendering (SSR) to dynamically generate HTML from the server in response to requests. Rendering from the server helps apps to load fast 🚀 because all of the hard work of fetching the data and deciding how to display it has already been done on the server - the client just has to display the already rendered HTML. They can take advantage of powerful server hardware and directly access backend data and services.
2. Blazor: Blazor's component model is focused on handling UI interactions from the client. Server-side rendering requires every UI interaction be sent to the server, so it isn't great for richly interactive UI. For rich interactivity 🎮 you want to use client-side rendering (CSR), which has much lower latency and can readily access client capabilities.

Many modern web apps need to use a combination of these approaches, both server-side rendering and client-side rendering. Maybe your home page or blog is best handled with server-side rendering so that it loads fast and is easily indexed, while the more elaborate functionality of your app needs the responsiveness of running from the client. Currently, with .NET, this requires using multiple different frameworks together: MVC, Razor Pages, and Blazor.

This issue proposes to combine the benefits of server-side and client-side rendering into a single consistent model based on Blazor , that we're currently calling Blazor United (name subject to change). Blazor in .NET 8 will enable you to use a single Blazor-based architecture for all your web UI scenarios. You can use Blazor components to render HTML directly from the server and also enable full client-side interactivity with Blazor Server or WebAssembly. That's all within a single project with the ability to easily switch between different rendering modes and even mix them in the same page. Blazor in .NET 8 will also enable new rendering capabilities like streaming rendering and progressive enhancement of navigations and form posts.

@SteveSandersonMS put together a video of an early prototype that demonstrates many of the intended capabilities.

Related issues:

• Streaming rendering #46352
• [Design] Blazor United: Layering architecture #46393
• Render a server component into the page #46353
• Render a webassembly component into the page #46354
• We can interleave Static/Server/WebAssembly components within an app #46394
• We have a project template where we can add support for Server and Webassembly #46395
• API for registering endpoints that render Razor components. #46350
• Auto switching for interactive components #46397
• Unified project system (new TFM integration with build/publish/SWA) #46398
• Progressive enhancement of form submission & navigation #46399

[mammadkoma]

If we use MudBlazor components and then use RenderMode.Auto, it loads first the page server side then after download the MudBlazor components and other wasm dll load and work on client side browser? We only want to increase the startup speed.

[chrissainty]

What will the programming experience be when authoring components? Will we need platform checks to decide if were running on WASM or Server and then decide to call an API or a local service?

[ahazelwood]

Blazor United brings a lot of functionality to a table, but I'm curious how it will handle the following scenarios:

1. RenderMode.Auto is used and for some reason the Websocket connection is cancelled because of a new build deployment. Will the data the client sees survive this? Or will the user have to re-enter any data they may have provided? (This assumes no major changes to the underlying parameters).
2. If I update a Razor component, will it be smart enough to only download the changed assembly and not the entire wasm framework on a new deployment?

[marcoatribeiro]

How will HttpContext be handled by Blazor United, as it is available in Blazor Wasm but not in Blazor Server?

[danroth27]

If we use MudBlazor components and then use RenderMode.Auto, it loads first the page server side then after download the MudBlazor components and other wasm dll load and work on client side browser? We only want to increase the startup speed.

@mammadkoma With the Auto render mode the app loads first using Blazor Server. The .NET WebAssembly runtime is downloaded in the background and cached so that it can be used on subsequent navigations to that page. The idea is to ensure the app always loads fast while pushing load off of the server as soon as possible.

[danroth27]

What will the programming experience be when authoring components? Will we need platform checks to decide if were running on WASM or Server and then decide to call an API or a local service?

@chrissainty The expectation is that the vast majority of components should be authored to function with all rendering modes. Otherwise, you dilute the value of component reusability! But we do want to enable scenarios where you need to platform specific things. That's where the normal .NET tricks of using cross-compilation and runtime checks come in to play.

[mammadkoma]

If we use MudBlazor components and then use RenderMode.Auto, it loads first the page server side then after download the MudBlazor components and other wasm dll load and work on client side browser? We only want to increase the startup speed.

@mammadkoma With the Auto render mode the app loads first using Blazor Server. The .NET WebAssembly runtime is downloaded in the background and cached so that it can be used on subsequent navigations to that page. The idea is to ensure the app always loads fast while pushing load off of the server as soon as possible.

So we can use MudBlazor wasm components. But what about if the user doesn't change the page? All requests are blazor server mode until the user change the navigation? Or after the dlls are downloaded in background the wasm mode work?

[danroth27]

How will HttpContext be handled by Blazor United, as it is available in Blazor Wasm but not in Blazor Server?

@marcoatribeiro Great question. I don't think we have a clear answer for this yet. The related work is tracked by #46393. Proposals on how you think should work are welcome!

[danroth27]

So we can use MudBlazor wasm components. But what about if the user doesn't change the page? All requests are blazor server mode until the user change the navigation? Or after the dlls are downloaded in background the wasm mode work?

@mammadkoma Right, the page would continue to use Blazor Server initially and would only transition to use Blazor WebAssembly on a subsequent page load. This avoids a bunch of complexity with trying to transition from Blazor Server to Blazor WebAssembly while the page is still active. It does mean that if the user stays on the page for a long time the circuit might be long lived.

[mihaimyh]

What about dlls being blocked by some antiviruses, even renaming the extension from .dll to something else doesn't help. This will make the transition to Wasm impossible.

[bub-bl]

Before we start, very good work! I appreciate the work you provide for the .NET platform. I have a question related to rendering. Let's say I have a page that is rendered by WebAssembly, in this page I have a component that is rendered by the server, can I share data with the components that do not share the same rendering mode? Are the cascaded values still functional even if the parent and child don't share the same rendering mode?

[danroth27]

What about dlls being blocked by some antiviruses, even renaming the extension from .dll to something else doesn't help. This will make the transition to Wasm impossible.

@mihaimyh See dotnet/runtime#80807 for our effort to address this.