Blazor Render Modes: SSR, Server, WebAssembly — and What's Next

Previously, ClinicApp reached across the internet with HttpClient and fetched real data from a web API — and now, in our series finale, it's time to keep a promise we made all the way back in Part 1.

A promise kept

Since the very first part, every interactive page in ClinicApp has carried one mysterious line: @rendermode InteractiveServer. You typed it, it worked, and we said "trust us, we'll explain later." Later is now. That line answers one of the most important questions in Blazor: where does your C# code actually run, and how does the page become interactive?

In current Blazor — the .NET 10 LTS era — there are four answers to that question, called render modes. Here they are side by side:

Static SSR: plain HTML, blazing fast

With static server-side rendering, the server runs your component once per request, produces plain HTML, sends it, and hangs up. No buttons that count clicks, no live updates — but pages load incredibly fast, work on any device, and search engines adore them. Fun fact: the very site you're reading is Blazor static SSR! A blog doesn't need click handlers; it needs to get words in front of you instantly.

Interactive Server: the mode ClinicApp used all series

Interactive Server is what @rendermode InteractiveServer gave us. Your C# stays on the server, and the browser keeps a live connection open (a technology called SignalR). Click a button, and the event zips to the server; the server runs your code, works out what changed on the page, and zips the tiny difference back. It feels local, but it's a conversation.

The trade: the download is tiny — Blazor's client script is now only around 43 KB, roughly 76% smaller than it used to be, so interactive pages start fast — but you need a steady connection, because no connection means no events. Blazor even plans for that: the Blazor Web App template ships with a built-in ReconnectModal that politely tells users the connection dropped and reconnects them automatically.

Interactive WebAssembly: C# inside the browser

Interactive WebAssembly flips the arrangement: your C# is compiled to WebAssembly and runs inside the browser itself. No round trips — clicks are handled right there on the user's machine, and the app can even keep working offline. The cost is a bigger first download, since the browser needs the .NET runtime and your code before anything interactive happens. After that first visit, caching makes return trips much quicker.

Interactive Auto: the best of both

Can't choose? Interactive Auto starts your component in Server mode so users get instant interactivity, quietly downloads the WebAssembly bits in the background, and on future visits runs in the browser. First impressions of Server, long-term independence of WebAssembly.

The four modes at a glance

So how do you choose?

• Content site or blog? Static SSR. Speed and SEO win.
• Internal tool on a reliable office network? Interactive Server — tiny downloads, all your code safely on the server.
• Needs to work offline, or as a PWA? Interactive WebAssembly.
• Polished consumer app where first impressions matter? Interactive Auto.

And here's Blazor's quiet superpower: you don't pick one mode for the whole app. Render modes apply per component or per page. Your marketing pages can be static SSR while your dashboard runs Interactive Server and one special widget runs WebAssembly — all in the same project, exactly like ClinicApp mixed static and interactive pages without us making a fuss about it.

One last teaser: talking to JavaScript

Occasionally you'll want a browser feature or JavaScript library that C# can't reach directly — maps, charts, the clipboard. Blazor's answer is JS interop: inject IJSRuntime and you can call JavaScript functions from C# (and C# from JavaScript). You won't need it often, but when you do, it's one @inject away — a lovely topic for your own exploring.

Look how far you've come

Twelve parts ago, ClinicApp didn't exist. Since then, you have:

• Created a Blazor Web App from scratch and understood its moving parts (Part 1)
• Built reusable components like PatientCard and passed them parameters
• Modeled data with a Patient class and rendered lists of it
• Wired up routing, including URL parameters like /patients/{id:int}
• Handled events and forms with search and an add-patient form
• Shared data through services and dependency injection (Part 9)
• Mastered the component lifecycle and the loading-state pattern (Part 10)
• Called a real web API with HttpClient (Part 11)
• And today, understood exactly where your code runs — in every mode Blazor offers

That is not a beginner's checklist anymore. That's the working vocabulary of a real Blazor developer.

Where to next?

ClinicApp is begging for a few upgrades, and each one is a wonderful next adventure:

• A real database. Right now patients vanish when the app restarts. Persisting them is the natural next step — start with SQL vs NoSQL: which to learn first, and if you followed our clinic design series, its conclusion hands you a ready-made database design for this very domain. The two series were always meant to meet.
• Authentication. Real clinics need logins — patients' data deserves a locked door. ASP.NET Core Identity plugs into Blazor beautifully.
• Deployment. Put ClinicApp on the internet! Publishing to a cloud host is far less scary than it sounds.

And that's a wrap on Blazor: Beginner to Intermediate. Twelve parts, one clinic, and a version of you that can build interactive web apps in C# — genuinely, congratulations. Thank you for building alongside us; teaching you has been a joy. If there's a topic you'd love this site to cover next, tell us through the contact page — reader suggestions have a habit of becoming series around here. Until then: keep building, keep shipping, and be kind to your future self with good commit messages. Happy coding!