Blazor, React, and ASP.NET Core MVC
Mental Models and Translation

This Dev Note is about translating between three different ways of thinking about web applications: ASP.NET Core MVC, Blazor, and React.

The goal is not to argue that one framework is superior to the others. The goal is to clarify the mental models behind them, especially from the perspective of someone whose first exposure to MVC was ASP.NET Core MVC.

Main Focus

Mental models, architecture, and conceptual translation

Frameworks

ASP.NET Core MVC, Blazor, React

Use Case

Understanding how UI logic is organized across different paradigms

Why This Comparison Matters

A lot of framework confusion is really paradigm confusion. Developers often struggle not because a tool is especially complicated, but because they are thinking about it using assumptions borrowed from a different architecture.

That is especially true when moving between a request-driven framework like ASP.NET Core MVC and component-based frameworks like Blazor or React.

A useful way to frame this is: different frameworks teach different habits of thought. The code changes, but so does the way you imagine the application itself.

My Starting Point: ASP.NET Core MVC

My first exposure to MVC was through ASP.NET Core MVC. That matters, because it shaped my initial understanding of how a web application was supposed to work.

In that model, the application tends to feel organized around requests: a request arrives, a controller handles it, data is prepared, and a view is rendered.

That workflow makes a lot of sense, but it is different from the way component frameworks encourage developers to think.

MVC Thinking

In ASP.NET Core MVC, the web application is often mentally organized around this sort of flow:

Request → Controller → Model/Data → View → HTML Response

The controller acts as an orchestrator. It receives the request, performs logic or coordinates data access, and then returns a view. The Razor view is typically used to render the resulting HTML.

Example controller action:

public IActionResult Index()
{
    var message = "Hello from the controller";
    return View(model: message);
}

Example Razor view:

<h3>@Model</h3>

This is a very server-driven model. Each request tends to produce a complete response. When the user needs something new, the browser usually makes another request.

React Thinking

React encourages a different mental model. Instead of organizing the UI around controllers and requests, it organizes the interface around components, state, and events.

A simple React-oriented mental loop looks like this:

State → Render → Event → State

The UI exists as a tree of components. Each component renders based on its current state and props. When an event occurs, state changes, and the component re-renders.

Example React component:

function App() {
  const [message, setMessage] = React.useState("Hello from React");

  return (
    <>
      <h3>{message}</h3>
      <button onClick={() => setMessage("The component updated!")}>
        Click me
      </button>
    </>
  );
}

In React, the logic lives inside the component rather than in a separate controller. That is a major conceptual shift for someone coming from MVC.

Blazor Thinking

Blazor shares much of the same component-oriented logic as React, but it expresses that logic using Razor components and C# instead of JavaScript and JSX.

A Blazor component can contain markup, state, and event-handling logic in a single .razor file.

Example Blazor component:

<h3>@message</h3>

<button @onclick="ChangeMessage">Click me</button>

@code {
    string message = "Hello from Blazor";

    void ChangeMessage()
    {
        message = "The component updated!";
    }
}

This is one reason Blazor can feel familiar and unfamiliar at the same time for a .NET developer. The language is familiar, but the organizing principle is different from MVC.

Blazor often makes the most sense when thought of as a .NET component framework, not as “MVC but with more interactivity.”

The Biggest Shift: Where the Logic Lives

One of the clearest differences between these approaches is where application behavior tends to live.

Approach	Primary Organizing Unit	Where Logic Tends to Live	Typical Flow
ASP.NET Core MVC	Request / Controller / View	Controller actions and related server logic	Request → process → render response
React	Component	Inside components and hooks	State → render → event → state
Blazor	Component	Inside Razor components and C# methods	State → render → event → state

This means that moving from MVC to Blazor is not just a syntax change. It is a shift from thinking primarily in terms of request orchestration to thinking in terms of component composition and state flow.

Why Blazor Can Feel Like a Bridge

Blazor occupies an interesting middle ground.

Like MVC, it belongs to the .NET ecosystem and often feels familiar to C# developers
Like React, it uses a component-based UI model
Like modern frontend frameworks, it encourages event-driven, state-oriented thinking

Because of that, Blazor can serve as a conceptual bridge for developers moving from traditional server-rendered .NET applications toward more interactive component-based architectures.

What an MVC Developer Might Accidentally Do in Blazor

Someone coming from ASP.NET Core MVC may be tempted to think:

Where is the controller for this interaction?
Where do I put the logic that changes the page?
What action returns the updated view?

But Blazor usually wants a different answer:

The component often handles its own UI behavior
State changes cause rendering changes
Component composition replaces some responsibilities that once lived in controllers

Trying to force an MVC mental model directly into Blazor can make Blazor feel awkward or overly complicated. Sometimes the friction is not the framework itself but the inherited assumptions brought into it.

A Simpler Reframe

A helpful translation is this:

MVC organizes the application around requests
React organizes the application around components and state
Blazor also organizes the application around components and state, but in C#

That is not the whole story, but it is a strong starting point.

Server Rendering vs Living UI

Another helpful distinction is the difference between a page as a response and a page as an interactive system.

In MVC, the page often feels like something generated in response to a request. In Blazor and React, the page feels more like a living interface that persists and changes over time.

That changes the developer’s job. Instead of asking only “what HTML should this request return?” you start asking “what state does this component have, and how should the UI react when that state changes?”

Why This Translation Helped Me

Because my first exposure to MVC was ASP.NET Core MVC, a lot of my early thinking about web apps was shaped by controllers, actions, and views. That model was useful, but it did not automatically prepare me for component-based UI frameworks.

Understanding Blazor became easier once I stopped trying to look for MVC-style answers to every problem. Instead, it helped to think in terms of components, state, rendering, and events.

React made that pattern even more visible, because it strips the model down to its component logic more plainly. Blazor, in turn, became easier to understand as a .NET expression of a component-driven UI model.

A Compact Summary

ASP.NET Core MVC:
Request → Controller → View

React:
State → Render → Event → State

Blazor:
State → Render → Event → State
(using Razor and C#)

That summary is simplified, but it captures the main conceptual translation.

Why This Matters for Learning

A framework becomes easier to learn when its underlying mental model is clear. Without that model, it is easy to build by imitation while still feeling confused underneath.

The point of comparison is not to flatten every framework into the same thing. It is to understand what each one is trying to optimize and how each one teaches developers to organize problems.

A useful next Dev Note could compare specific patterns across these approaches, such as routing, forms, component communication, or state management.

Blazor, React, and ASP.NET Core MVCMental Models and Translation