Quick answer: Blazor lets you build interactive web UI with C# instead of JavaScript as the main language. Blazor Server, shipping with .NET Core 3.0 in September 2019, runs components on the server and sends UI updates over a SignalR connection. Blazor WebAssembly, generally available with .NET Core 3.1 in May 2020, runs those components in the browser on WebAssembly. Choose Server when you want a thin client, fast first load and tight database access. Choose WebAssembly when you need richer client-side work, offline potential or less permanent server connection state.
What Blazor is (mid-2020)
Blazor is Microsoft’s component model for .NET web UI. You write Razor components with C# and HTML markup. The same component model can run in two hosting models that feel similar in code but behave differently in production.
As of July 2020 you are working with Blazor on .NET Core 3.1 for WebAssembly and 3.0+ for Server. Later .NET releases are not part of this picture yet. If your team is still on .NET Framework for older apps, Blazor will not drop into that stack; you need .NET Core. Our overview of moving from .NET Framework to .NET Core covers that migration decision.
Blazor Server in plain terms
With Blazor Server:
- Components execute on the server
- The browser holds a lightweight UI shell
- A persistent SignalR circuit carries events and DOM diffs
- Your code can use full server .NET APIs and talk to databases directly (with normal care)
Strengths
- Small initial download compared with a full WebAssembly runtime and app bundle
- Logic and secrets stay on the server more naturally
- Existing server libraries are easier to reuse
- Good fit for internal tools on reliable networks
Trade-offs
- Needs a constant connection; flaky mobile networks hurt
- Every click or keystroke that triggers a component event involves the server
- Server memory scales with active circuits
- Latency is bound to network round trips
Blazor Server shines for line-of-business apps on corporate networks, admin back offices and dashboards where clients are online and relatively close to the server.
Blazor WebAssembly in plain terms
With Blazor WebAssembly:
- The .NET runtime and your app download to the browser
- Components execute on the client
- HTTP calls (or similar) reach your APIs for data
- Offline or occasionally connected scenarios become realistic once you design for them
Strengths
- UI interactions can stay local after the app is loaded
- Server can be a normal API farm without per-user UI circuits
- Public-facing rich clients are more natural
- Closer to the SPA model teams know from other frameworks
Trade-offs
- Larger first load (runtime + assemblies) than Blazor Server
- Browser CPU and payload size matter more
- You must expose APIs carefully; do not ship secrets in client code
- Debugging and tooling are newer than mature JS SPA stacks
Blazor WebAssembly is young as a supported release (May 2020). Expect rapid learning across the community, and budget time for payload sizing and auth patterns.
Side-by-side decision factors
Latency and network
If users are on unreliable mobile connections, Server circuits will frustrate them. WebAssembly can keep the UI responsive while requests retry, if you design it that way.
Security and data access
Server-side code can sit closer to the database with classic server security patterns. WebAssembly must treat the client as hostile and put business rules in APIs. That is normal for SPAs, but teams new to Blazor sometimes forget it.
Scaling
Blazor Server: plan for concurrent circuits, sticky sessions or compatible load balancing, and memory. Blazor WebAssembly: scale static hosting plus APIs the way you would for other SPAs.
Team skills
Both models reward strong C# skills. You still need HTML, CSS and browser knowledge. If the team already builds ASP.NET Core Web APIs, WebAssembly + API is a familiar split. If they build Razor Pages or MVC server apps, Blazor Server may feel closer.
Offline and installable feel
WebAssembly is the path toward offline-capable experiences. Blazor Server is not.
SEO and first content
Public marketing pages often still suit classic server-rendered MVC or Razor Pages. Many teams keep the marketing site separate and use Blazor for the authenticated app. Neither Blazor hosting model is a magic SEO replacement for well-rendered content pages.
When to pick Blazor Server
Choose Blazor Server when:
- The app is internal or behind login on a solid network
- First load size must stay small
- Developers need direct access to server resources
- You want to adopt Blazor with less client payload work
- Offline is not a requirement
Examples: inventory admin, internal reporting, customer support consoles, configuration tools.
When to pick Blazor WebAssembly
Choose WebAssembly when:
- You want rich client interactivity after load
- You prefer scaling APIs and static files
- Users may go offline or roam between networks
- You are building a product UI closer to a SPA
- You can invest in payload trimming and API design
Examples: customer portals with heavy client interaction, field tools with intermittent connectivity, products where C# shared with other .NET clients matters.
Hybrid and pragmatic patterns
You do not have to put the entire company website on Blazor. Common patterns in 2020:
- Marketing site in CMS or Razor Pages; app in Blazor
- Start on Blazor Server to learn components; revisit WebAssembly later for a public client
- Shared Razor class libraries for components used in more than one host
Also keep expectations honest relative to mature JS frameworks. React, Angular and Vue still have deeper ecosystems for some UI problems; Blazor’s pitch is productivity for .NET shops, not universal replacement overnight. Our older comparison of React vs Angular vs Vue is still useful when the alternative is a JS SPA rather than Blazor.
Delivery checklist for either model
- Auth story decided (cookies, tokens, identity provider)
- Environment configuration for API bases and secrets
- Logging and error boundaries
- Automated tests for critical components and APIs; see unit testing in .NET
- Performance budget for first load (especially WebAssembly)
- Load testing for concurrent Blazor Server circuits if that is your host
- CI deploy to staging before production
FAQ
Is Blazor ready for production in July 2020?
Blazor Server has been production-ready longer. Blazor WebAssembly became generally available in May 2020, so it is supported, but teams should pilot carefully and watch payload size and browser support needs.
Do I still need JavaScript?
Often a little. Blazor can interop with JavaScript for browser APIs and existing libraries. Many apps are mostly C# with small JS islands.
Can I switch hosting models later?
Component code can transfer more easily than people expect, but architecture around state, auth and data access still needs rework. Plan the hosting model on purpose rather than assuming a free swap.
Should we rewrite an MVC app into Blazor now?
Only if you have a clear UX or maintenance reason. Incremental adoption beats a big rewrite.
Pick the host that matches the network and the app
Blazor Server and Blazor WebAssembly share a component model and diverge on where code runs. Match that choice to latency, scaling, offline needs and team strength. If you want help choosing a .NET approach for a business app, see our custom development work.
