Blazor Server vs WebAssembly: Choosing the Right Model

Blazor offers two hosting models: Blazor Server (launched with .NET Core 3.0) and Blazor WebAssembly (Wasm, arriving May 2020). While they share the same component model and Razor syntax, their architectural characteristics are diametrically opposed. This guide dissects the SignalR-based state management of Server vs. the monolithic download of Wasm, helping you decide which fits your enterprise app.

Architecture Comparison

flowchart TB
    subgraph "Blazor Server"
        Browser1["Browser DOM"] <-->|SignalR (Binary)| Server["ASP.NET Core Server"]
        Server -->|Render Tree Diff| Browser1
        Server -->|Event Handling| Database1[(Database)]
    end
    
    subgraph "Blazor WebAssembly"
        Browser2["Browser Wasm Runtime"]
        Browser2 -->|REST / gRPC| API["API Gateway"]
        API --> Database2[(Database)]
        Browser2 -->|Client-Side Logic| Browser2
    end
    
    style Server fill:#E1F5FE,stroke:#0277BD
    style Browser2 fill:#FFF3E0,stroke:#E65100

Blazor Server: The “Thin Client”

In Blazor Server, the app executes on the server. UI updates, event handling, and JavaScript calls are handled over a SignalR connection.

• Pros: Instant load time (small download), code stays on server (secure secrets), full .NET Core runtime access.
• Cons: No offline mode, high latency (every click is a roundtrip), high server memory (per-user state).
• Ideal For: Internal LOB apps, high-security apps.

// Server-side Service Injection (Direct DB Access possible but discouraged)
@inject IOrderRepository OrderRepo

<button @onclick="SubmitOrder">Order</button>

@code {
    async Task SubmitOrder()
    {
        // Runs on Server!
        await OrderRepo.SaveAsync(new Order());
    }
}

Blazor WebAssembly: The “Fat Client”

Blazor Wasm downloads a .NET runtime (dotnet.wasm) and your DLLs to the browser. It runs purely client-side.

• Pros: Offline support (PWA), zero latency for UI interactions, serverless backend feasible.
• Cons: Large initial download (2-10MB), restricted runtime (browser sandbox), secrets must effectively use an API.
• Ideal For: Public-facing apps, high-interactivity dashboards.

Handling Latency in Blazor Server

Since every event goes to the server, network reconnection is critical.

// _Host.cshtml
<component type="typeof(App)" render-mode="ServerPrerendered" />

<div id="reconnect-modal" style="display: none;">
    Attempting to reconnect to server...
</div>

<script src="_framework/blazor.server.js" autostart="false"></script>
<script>
    Blazor.start({
        reconnectionHandler: {
            onConnectionDown: () => document.getElementById('reconnect-modal').style.display = 'block',
            onConnectionUp: () => document.getElementById('reconnect-modal').style.display = 'none'
        }
    });
</script>

Key Takeaways

• Use **Server** for intranet apps with reliable networks to simplify architecture.
• Use **WebAssembly** for public apps requiring offline capability or scalability at the edge.
• Abstract your logic into shared libraries (.NET Standard) to switch models later if needed.