Blazor vs MVC vs Razor Pages

Analogy categoryAnalogies

Three Different Programming Models

ASP.NET Core offers three distinct approaches for building web UI, and choosing between them is an architectural decision, not just a syntax preference. MVC (Model-View-Controller) centers on controllers that coordinate data and select a view to render server-side, well-suited to content-heavy sites, public-facing pages, and APIs sharing a project with HTML views. Razor Pages is a page-focused variant that colocates a view with its handler logic per page, trading MVC's controller/action indirection for simpler, self-contained page files, ideal for forms and CRUD-style screens. Blazor departs from both by running actual C# component logic that produces UI, either server-side over a persistent SignalR connection (Blazor Server) or client-side in the browser via WebAssembly (Blazor WebAssembly/WASM), giving you SPA-like interactivity without hand-written JavaScript.

🏏

Cricket analogy: This is like choosing between Test cricket (MVC, structured, methodical, built for the long content-heavy innings), a T20 franchise game (Razor Pages, fast, focused, self-contained per-match logic), and a video game cricket simulation like Cricket 22 (Blazor, an interactive, responsive experience running its own engine) — three different formats for fundamentally different needs.

Blazor Server vs Blazor WebAssembly

Blazor Server executes component code on the server inside an ASP.NET Core process and keeps a live SignalR connection open to the browser, streaming only UI diffs down and user events back up, which means fast initial load and full access to server resources but requires a constant, low-latency connection and server-side memory per active circuit. Blazor WebAssembly instead downloads the compiled .NET runtime and your app's assemblies to the browser and runs entirely client-side, giving true offline capability and no per-user server circuit cost, at the price of a larger initial download and needing explicit HTTP calls (typically to a separate Web API) for any server or database access.

🏏

Cricket analogy: This is like the difference between watching a match via a live TV feed that must stay connected every second to show you anything (Blazor Server's persistent SignalR link) versus downloading a full match highlights app to your phone that works even with no signal once downloaded (Blazor WASM's offline-capable client runtime).

razor

@* Counter.razor - works the same in Blazor Server or Blazor WebAssembly *@
@page "/counter"

<h3>Counter</h3>
<p role="status">Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

// Program.cs (Blazor Server)
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();
// ...
app.MapRazorComponents<App>()
   .AddInteractiveServerRenderMode();

Choosing Based on Interactivity Needs

The deciding factor is usually how much client-side interactivity a page genuinely needs and how much that interactivity has to survive a page reload or work offline. A marketing site or blog with mostly static, SEO-sensitive content is well served by MVC or Razor Pages rendering plain HTML with minimal JavaScript, since search engines and low-powered devices get fast, simple pages. A dashboard with live-updating charts, drag-and-drop reordering, or complex client-side state that must persist across navigation without full page reloads is a much stronger fit for Blazor, since components re-render efficiently in place instead of the browser reloading the whole page for every interaction; ASP.NET Core 8+ further blurs the line with render modes that let you mix static server rendering and interactive Blazor components on the same page.

🏏

Cricket analogy: This is like a static scorecard page for a match that finished last year, which just needs to load fast and be indexable (MVC/Razor Pages), versus a live match center with a real-time worm graph and ball-by-ball commentary updating without a page reload (Blazor's in-place re-rendering).

Since ASP.NET Core 8, Blazor supports per-component render modes (Static Server, Interactive Server, Interactive WebAssembly, and Interactive Auto) within a single app, letting you render most of a page statically for fast load and SEO while opting individual components into interactivity only where genuinely needed.

Blazor Server's persistent SignalR circuit means each connected user consumes server-side memory and CPU for the lifetime of their session; it does not scale the same way as stateless MVC/Razor Pages requests, and network interruptions can visibly disrupt the UI. Load-test expected concurrent circuit counts before committing to Blazor Server for a high-traffic public application.

MVC suits content-heavy, controller-orchestrated apps and APIs sharing a project with server-rendered HTML.
Razor Pages suits page-focused, self-contained CRUD/forms workflows without controller indirection.
Blazor runs actual C# component logic to produce interactive UI, either on the server or in the browser.
Blazor Server streams UI diffs over a persistent SignalR connection; fast start, but needs constant connectivity and per-user server memory.
Blazor WebAssembly runs the .NET runtime in-browser; larger initial download, but offline-capable with no per-user server circuit.
Choose based on interactivity needs: static/SEO-heavy content favors MVC/Razor Pages, rich stateful UI favors Blazor.
ASP.NET Core 8+ render modes let you mix static rendering and interactive Blazor components on the same page.