Blazor or MVC and Razor Pages for an internal business application?

A .NET team is about to build an internal application: orders, approvals, reports. Half the team knows ASP.NET MVC or Razor Pages inside out, and both are proven, stable and well documented. Someone suggests Blazor instead. Is it worth it?

Microsoft’s own guide to choosing a web UI is clear: Blazor is recommended for most web UI scenarios. But that does not mean every MVC application should be rewritten. The real questions are how interactive the screens are, and what you already have.

The difference in three sentences

• MVC: controllers receive the request, prepare the data and return a view. Every click that needs the server is a new request.
• Razor Pages: the same idea, organised per page instead of per controller. Simpler for form-heavy applications.
• Blazor: the screen is built from C# components. They can be rendered on the server like Razor Pages, or run interactively, on the server or in the browser through WebAssembly.

The same form in both

A simple form for a new order. In Razor Pages, the page and its handler:

@page
@model NewOrderModel

<form method="post">
    <input asp-for="Order.Customer" />
    <span asp-validation-for="Order.Customer"></span>
    <button>Save</button>
</form>

public class NewOrderModel(OrderService orders) : PageModel
{
    [BindProperty]
    public OrderInput Order { get; set; } = new();

    public async Task<IActionResult> OnPostAsync()
    {
        if (!ModelState.IsValid)
            return Page();

        await orders.CreateAsync(Order);
        return RedirectToPage("Index");
    }
}

In Blazor, one component:

@inject OrderService Orders
@inject NavigationManager Navigation

<EditForm Model="Order" OnValidSubmit="SaveAsync" FormName="new-order">
    <DataAnnotationsValidator />
    <InputText @bind-Value="Order.Customer" />
    <ValidationMessage For="() => Order.Customer" />
    <button>Save</button>
</EditForm>

@code {
    [SupplyParameterFromForm]
    private OrderInput? Order { get; set; }

    protected override void OnInitialized() => Order ??= new();

    private async Task SaveAsync()
    {
        await Orders.CreateAsync(Order!);
        Navigation.NavigateTo("/orders");
    }
}

For a simple form, the two are about the same amount of work. The difference appears the moment the screen has to react: the price recalculates as the quantity changes, the second dropdown depends on the first, the list filters as you type. In MVC and Razor Pages, that is JavaScript next to the C#. In Blazor, it stays in C#, in the same component.

Compared by what matters to the business

	Blazor	MVC and Razor Pages
Interactive screens	In C#, without separate JavaScript	JavaScript, or a library such as htmx, next to the C#
Simple forms and lists	As easy	As easy, and very mature
Reusable parts of the screen	Components, used across the application	Partial views and tag helpers, less natural
Public pages and SEO	Good with static server rendering	Excellent, a natural fit
Server resources	Interactive server mode keeps a connection per open browser tab	A request, a response, nothing kept
The team	C# developers become productive quickly	Most .NET developers already know it
Existing application	Can be added to it, screen by screen	Stays as it is

The server row deserves a sentence. Blazor in interactive server mode keeps a live connection for every open tab. For an internal application with a few hundred users, that is not a problem. For a public site with thousands of visitors, use static rendering or WebAssembly for those pages. Our article on Blazor Server vs WebAssembly covers when to use which.

When MVC or Razor Pages remains the right choice

• A large MVC application already works. Rewriting it only to change the framework rarely pays off.
• Mostly forms and static pages, with little interaction on the screen.
• Public content that has to load fast and rank on Google.
• A team that knows MVC well and has no need for richer screens.

You rarely have to choose only one

Blazor components can live inside an existing MVC or Razor Pages application. That makes the safest path a gradual one: the existing screens stay as they are, and the new, more interactive ones are written in Blazor. Over time, the application moves at the pace the business needs, without a big rewrite. The same approach works for older applications; see our article on moving from Web Forms to Blazor.

Five questions before you decide

1. How much of the application is forms and lists, and how much is screens that react as you work?
2. Is there an existing MVC or Razor Pages application, and does it work?
3. Is the application internal or behind a login, or public and dependent on Google?
4. How many users will have it open at the same time?
5. Who maintains it in five years, and what do they know?

If the answers point to interactive screens, a login and a C# team, choose Blazor for the new work. If they point to a working MVC application with mostly forms, keep it and add Blazor only where a screen really needs it. How Blazor compares with the JavaScript frameworks is in Blazor vs Angular and Blazor vs React.

How we work

ProCoding is a .NET studio from Split, Croatia. We maintain MVC and Razor Pages applications and have been shipping Blazor to production since 2020, so we have no reason to push one over the other. We help you choose, build new Blazor applications, and bring Blazor into existing applications one screen at a time. The first step is a free 30-minute call.

Sources

• Choose an ASP.NET Core web UI, Microsoft Learn
• ASP.NET Core Blazor render modes, Microsoft Learn
• Integrate ASP.NET Core Razor components into ASP.NET Core apps, Microsoft Learn