Render Modes in .NET 8+
.NET 8 unified Blazor Server and Blazor WebAssembly into a single project template and introduced explicit per-component render modes: Static Server (no interactivity, pure server-rendered HTML), Interactive Server (logic runs on the server over a SignalR circuit), Interactive WebAssembly (logic runs in the browser via a downloaded .NET runtime), and Interactive Auto (starts on the server, then switches to WASM once the WebAssembly bundle finishes caching locally). This is a break from .NET 6/7 where an entire app committed to one hosting model at project-creation time.
Cricket analogy: It's like a team management deciding per-innings whether a player bowls spin from the pavilion end (server-controlled) or bats at the crease making live decisions (client-controlled), rather than locking the entire XI to one style for the whole series the way Blazor Server or WASM used to lock a whole app.
Interactive Server vs Interactive WebAssembly
Interactive Server keeps the .NET runtime on the server and streams UI diffs to the browser over a persistent SignalR connection; every button click, keystroke handler, and state change is a network round trip, so it has near-zero initial download size and full trust access to server resources like databases, but adds latency per interaction and requires a stable connection. Interactive WebAssembly downloads the Blazor WASM runtime (Mono compiled to WASM plus your app DLLs) and executes entirely client-side after that initial payload, giving offline capability and zero per-interaction latency but a larger first-load cost and no direct access to server-only resources without an API call.
Cricket analogy: It's the difference between a captain who needs a runner relaying instructions from the dugout for every single ball (Interactive Server's round trips) versus a self-sufficient opener like Rohit Sharma who reads the field and adjusts shot selection independently once set (WebAssembly's local execution), at the cost of needing time to 'get his eye in' first.
Interactive Auto and Choosing a Mode
Interactive Auto is the pragmatic middle path introduced in .NET 8: on a user's first visit it renders interactively over Interactive Server (fast, no download wait), while the WASM runtime and app assembly download and cache in the background using the browser cache; on subsequent visits, Blazor detects the cached WASM payload and boots straight into WebAssembly, giving you fast first paint and eventual offline-capable, latency-free interaction without the developer hand-rolling that logic. The trade-off is complexity: your component and its dependencies must work correctly under both hosting models (no server-only APIs called from code paths that might run client-side), and you pay for maintaining a dual-compatible mental model even though the framework handles the mechanics.
Cricket analogy: It's like a franchise fielding a promising young all-rounder as a specialist bowler in his first IPL match to get him game time fast (Server mode's quick start), while quietly training him in the nets to become a genuine all-rounder batsman for later matches (WASM caching in background), so by his third game he can do both.
@* Applied per-component, or per-page, in .NET 8+ *@
@page "/dashboard"
@rendermode InteractiveAuto
<h3>Live Dashboard</h3>
<p>Current mode is decided by the framework at runtime.</p>
@code {
// This component starts on Interactive Server, then hot-swaps
// to WebAssembly once the WASM payload is cached in the browser.
}
@* Program.cs registration for a unified Blazor Web App *@
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorComponents()
.AddInteractiveServerComponents()
.AddInteractiveWebAssemblyComponents();
var app = builder.Build();
app.MapRazorComponents<App>()
.AddInteractiveServerRenderMode()
.AddInteractiveWebAssemblyRenderMode()
.AddAdditionalAssemblies(typeof(Client._Imports).Assembly);
A component's render mode is a boundary, not a suggestion: code compiled into a WebAssembly-eligible component cannot reference server-only APIs (like EF Core DbContext direct injection) because that same assembly may execute in the browser. Guard server-only logic behind an API endpoint or keep those components fixed to InteractiveServer explicitly.
- Static Server render mode produces non-interactive HTML with no C# event handling in the browser.
- Interactive Server executes component logic on the server and streams UI updates over SignalR — small download, per-interaction latency.
- Interactive WebAssembly downloads the .NET runtime and app DLLs to run entirely in the browser — larger first load, zero per-interaction latency, works offline.
- Interactive Auto starts on Server for a fast first paint, then switches to cached WebAssembly on return visits, combining both benefits automatically.
- Render mode is set per component (or cascaded per page) using the @rendermode directive or an explicit RenderMode.InteractiveServer/WebAssembly/Auto value.
- Components intended for WASM execution must avoid server-only dependencies since the same assembly may run entirely client-side.
- Choosing a mode is a trade-off between initial load size, interaction latency, offline support, and access to server-only resources.
Practice what you learned
1. Which .NET 8 render mode gives the fastest first paint while still eventually enabling zero-latency client-side interaction?
2. Why can't a component intended for Interactive WebAssembly directly inject an EF Core DbContext the way a server-only component can?
3. What is the primary cost of Interactive Server mode compared to Interactive WebAssembly?
4. Before .NET 8, how did a Blazor project choose between Server and WebAssembly hosting?
5. What directive is used to set a component's render mode in .NET 8+?
Was this page helpful?
You May Also Like
How Blazor Server Uses SignalR
A deep dive into the persistent SignalR circuit that powers Blazor Server, covering how events and DOM diffs flow, reconnection behavior, and bandwidth tuning.
Performance Optimization and Virtualization
How Blazor's diffing pipeline determines render cost, and the practical techniques — Virtualize, ShouldRender, and parameter hygiene — used to keep large apps fast.
Blazor Hybrid with .NET MAUI
How Blazor Hybrid hosts Razor components natively inside .NET MAUI apps via BlazorWebView, enabling shared UI code across web, desktop, and mobile with native performance.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics