Blazor from Scratch: Chapter 1 — What is Blazor?

Welcome to Chapter 1 of Blazor from Scratch. If you missed the intro post where I laid out what this series is and who it’s for, start there first — it’s short.

In this chapter we’re going to answer the fundamental question: what is Blazor? That sounds simple, but the answer has a few layers, especially because “Blazor” has come to mean slightly different things over the years. By the end of this post you’ll know what Blazor is, how it fits into the .NET ecosystem, what the different rendering models are, and why you might — or might not — choose it over a JavaScript framework.

A brief history

Blazor started as an experimental project by Steve Sanderson at Microsoft around 2017. The idea was provocative: run C# in the browser using WebAssembly, eliminating the need for JavaScript entirely. It was a proof of concept, and the name was a deliberate mash-up of Blazer and Razor — the templating engine that Blazor would eventually be built on top of.

The experiment generated enough excitement that Microsoft took it seriously. Blazor shipped as part of ASP.NET Core 3.0 in September 2019, first as Blazor Server — a model that runs your C# code on the server and uses a real-time SignalR connection to push UI updates to the browser. Blazor WebAssembly followed in May 2020 as part of ASP.NET Core 3.1, bringing true client-side execution to the framework.

.NET 6 and 7 refined the developer experience. Then .NET 8, released in November 2023, fundamentally rethought the rendering model with what Microsoft called full-stack web UI. Static server-side rendering, streaming rendering, interactive server, interactive WebAssembly, and a new Auto mode all lived under one roof in a single project. .NET 9 built on this foundation and cleaned up rough edges.

That’s where we are today.

What Blazor actually is

At its core, Blazor is a component-based UI framework for .NET. You build your UI out of components — self-contained pieces of C# and HTML markup that can hold state, respond to events, and compose into larger structures. If you’ve worked with React or Vue, that mental model will feel familiar. The key difference is that instead of JavaScript, you’re writing C#.

Components in Blazor are written in .razor files. A .razor file mixes HTML markup with C# code using the Razor syntax you may already know from ASP.NET MVC views. Here’s what a simple component looks like:

@page "/counter"

<h1>Counter</h1>
<p>Current count: @currentCount</p>
<button @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

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

There’s no JavaScript in sight. The @onclick directive wires up the button click to a C# method. The @currentCount expression renders the current value. When the state changes, Blazor figures out what to update in the DOM.

That’s the core of it. Everything else — routing, dependency injection, forms, HTTP calls — is built on top of this component model.

The rendering models

This is where a lot of confusion lives, so let’s be precise. “Blazor” today refers to a family of rendering modes, not a single deployment model. Understanding the difference matters because it affects performance, infrastructure requirements, and what your components can and can’t do.

Static SSR

The simplest mode. Your Razor components render on the server to HTML and that HTML is sent to the browser. There’s no persistent connection, no WebAssembly, and no client-side interactivity by default. This is essentially what Razor Pages does, but using the component model.

Use this for content-heavy pages, landing pages, anything that doesn’t need live interactivity.

Interactive Server

Your component code runs on the server. A SignalR WebSocket connection is established between the browser and the server. When you click a button or type into an input, the event travels over the WebSocket to the server, your C# runs, the diff is computed, and the DOM updates are sent back to the browser.

Advantages: Full access to server resources (databases, file system, secrets). Fast initial load. Small download size. Works in browsers without WebAssembly support.

Disadvantages: Every user interaction requires a server round-trip, which adds latency. Server resources scale with the number of active connections. The app degrades if the connection drops.

Use this for line-of-business apps, internal tools, apps where server-side data access matters more than offline capability.

Interactive WebAssembly

The .NET runtime is downloaded to the browser and your app runs entirely on the client. After the initial download, the app works fully offline and every interaction is instant — no server round-trips for UI logic.

Advantages: True client-side execution. Works offline. Reduced server load once the app is loaded.

Disadvantages: Larger initial download (the .NET runtime + your app). Slower first load. You need an API to access server-side data.

Use this for offline-capable apps, tools that need immediate responsiveness, scenarios where server processing isn’t needed for UI.

Auto mode

Introduced in .NET 8. The app starts in Interactive Server mode (fast initial load, no waiting for WebAssembly to download). Once the WebAssembly files have been downloaded in the background, subsequent visits switch to WebAssembly mode automatically.

This gives you the fast first load of Server and eventually the full client-side execution of WebAssembly. It’s the most complex model to reason about, but it’s a practical default for many apps.

Mixing modes in the same app

In .NET 8 and later, you’re not locked into a single rendering mode for the whole app. A marketing landing page can be Static SSR; the authenticated dashboard can be Interactive Server; a data-visualization widget can be Interactive WebAssembly. The framework handles the transitions.

For this series we’ll start with Interactive Server because it’s the simplest to get working and has the most straightforward mental model. We’ll explore the other modes as we go.

How Blazor compares to JavaScript frameworks

If you’ve built with React, Angular, or Vue, this is probably the comparison you’re curious about.

The similarities are real. Blazor’s component model is deliberately similar to React’s. You have props (Parameters in Blazor), local state (fields in the @code block), lifecycle hooks, and the same one-way-down / events-up communication pattern. If you know React, you’ll feel at home within a few hours.

The key difference is the language. In Blazor you write C#. Your business logic, validation rules, and data models can all be shared between your Blazor frontend and your ASP.NET Core backend. No more duplicating a User class in TypeScript when you already have it in C#.

The ecosystem gap is real but shrinking. The npm ecosystem is enormous. The NuGet ecosystem for UI components is smaller, though it has grown substantially. If you need a specific charting library or a drag-and-drop widget, JavaScript still has more options. But for most line-of-business applications, what’s available in the .NET space is more than sufficient.

JavaScript interop exists for when you need it. Blazor lets you call JavaScript from C# and C# from JavaScript. For browser APIs that don’t have a .NET wrapper yet, or when you want to use an existing JS library, interop is available. It adds a layer but it’s not painful.

The honest answer: if your team is entirely JavaScript developers building a public-facing product where SEO, performance, and the npm ecosystem are critical, stick with JavaScript. If your team is .NET developers, if you’re building internal or line-of-business applications, or if code sharing between frontend and backend matters to you, Blazor is a compelling choice.

What you need to follow along

For the rest of this series you’ll need:

• .NET 9 SDK — download from dot.net
• An IDE — Visual Studio 2022 (Community edition is free), VS Code with the C# Dev Kit extension, or JetBrains Rider
• Basic comfort with C# — classes, properties, interfaces, async/await

That’s it. No Node, no npm, no webpack.

Up next

In Chapter 2 we’ll scaffold your first Blazor app, walk through the project structure, and make sure you can run it locally. By the end you’ll have a working app and a clear picture of what each file is doing.

See you there.