Hello! Welcome to your first lesson in our Blazor .NET course.
Given your extensive background in the .NET ecosystem, particularly with ASP.NET MVC, you're in a great position to quickly grasp Blazor's concepts. This first lesson addresses a foundational topic that will be critical for your kiosk project: understanding the two main ways Blazor applications can be hosted.
Today, we'll focus on explaining the differences between the Blazor Server and Blazor WebAssembly hosting models. By the end of this lesson, you will understand the architecture, trade-offs, and ideal use cases for each, enabling you to make an informed decision for your project. Your specific interest in offline capabilities for a kiosk makes this choice particularly important, and we will pay special attention to that requirement.
1. The Fundamental Difference: Where Does Your C# Code Run?
The most crucial distinction between Blazor Server and Blazor WebAssembly (Wasm) lies in the execution environment.
- Blazor Server: Your C# code and application logic execute on the server, inside an ASP.NET Core application. The browser acts as a "thin client," essentially a remote terminal for your UI.
- Blazor WebAssembly: Your C# code is compiled to a WebAssembly binary format and, along with a lightweight .NET runtime, is downloaded and executed directly within the user's browser.
To start, let's get the official definition from the source. The Microsoft Learn documentation provides a clear, authoritative explanation.
ASP.NET Core Blazor hosting models
Please read the introductory sections for Blazor Server and Blazor WebAssembly from the official Microsoft documentation. This will provide a solid definition of each hosting model.
In the document, please read the initial section titled 'Blazor Server' and the initial section titled 'Blazor WebAssembly'. Focus on understanding the role of SignalR in Blazor Server and how the .NET runtime is handled in Blazor WebAssembly.
The diagrams in that document are particularly helpful. Here is a similar one that crisply visualizes the architectural difference.
In essence:
- With Blazor Server, when a user clicks a button, the event is sent to the server over a real-time SignalR connection. The server processes the event, calculates the UI changes (the "diff"), and sends that small diff back to the browser to update the DOM.
- With Blazor WebAssembly, when a user clicks a button, the C# event handler runs directly in the browser. The UI is updated in-process, just like with JavaScript-based SPA frameworks.
2. Practical Implications of the Hosting Models
Now that we have the core concept down, let's explore the practical consequences of these different architectures. The following video provides an excellent, developer-focused overview of five key differences that stem from this architectural choice.
5 Differences between Blazor Server and Blazor WebAssembly
This video by Claudio Bernasconi breaks down five practical differences between the two models. It's a great way to see how the architectural theory translates into real-world development considerations.
Watch the video from the beginning until 07:33. Pay close attention to the points about project structure, the necessity of an API layer, and the different scalability characteristics. These will resonate with your experience architecting ASP.NET MVC applications.
To summarize and build on the video, here are the key takeaways:
| Feature | Blazor Server | Blazor WebAssembly |
|---|---|---|
| Execution | Server-side (in an ASP.NET Core app) | Client-side (in the browser via WebAssembly) |
| Connection | Requires a constant, low-latency SignalR connection. | Only needs a server connection for initial download and API calls. |
| Initial Load | Very fast. Only a small JS file and initial HTML are sent. | Slower. The .NET runtime and application DLLs must be downloaded. |
| Offline Support | Not possible. A lost connection terminates the session. | Fully supported. The app runs locally, making it ideal for PWAs and offline scenarios. |
| Security | High. All code remains on the server. Secrets are secure. | Application code is public. Requires a separate backend API for secure operations. |
| Scalability | Stateful. Each client maintains a connection and state ("circuit") on the server. Scales "up" well but scaling "out" is complex. | Stateless. The client manages its own state. Scales "out" easily via static file hosting and a stateless backend API. |
| API Access | Can directly access server resources (e.g., DbContext, file system). |
Must call a backend API over HTTP to access server resources. |
3. Making the Right Choice for Your Kiosk Project
With this information, we can now make an informed decision for your specific goal: building a SPA for a kiosk. Your primary requirements—offline capability and potential hardware integration—point strongly toward one model.
To solidify this, let's consult one more resource that focuses on the decision-making process.
Blazor WebAssembly vs. Server: Which One to Choose?
This Telerik article offers excellent, scenario-based advice on choosing the right model. It directly addresses performance, security, and use cases.
Please read the sections 'Key Differences Between Blazor WebAssembly (WASM) and Blazor Server' and 'When to Use Blazor WebAssembly vs. Blazor Server?'. Focus on how the pros and cons align with the needs of a kiosk application.
Applying the criteria to your kiosk project:
- Offline Capability: This is your most critical requirement. If the kiosk needs to function during network interruptions, Blazor WebAssembly is the only viable choice. A Blazor Server app would stop working the moment the connection is lost.
- Initial Load Time: Blazor Wasm has a larger initial download. For a kiosk, this is usually a one-time cost when the application is first launched or updated. Subsequent interactions are near-instantaneous, which is more important for user experience.
- Performance: Once loaded, a Wasm app's performance depends on the client's hardware. Modern kiosk hardware is typically powerful enough to provide a smooth experience. Processing is offloaded from the server, which is a major benefit.
- Hardware Integration: You mentioned an interest in JavaScript Interoperability for hardware access. While both models support this, in Blazor Wasm, the C# code making the JS call is running on the same machine as the browser and the hardware. This creates a more direct and reliable integration path compared to the server-client-hardware round trip in Blazor Server.
Based on this analysis, Blazor WebAssembly is the clear and recommended choice for your kiosk project. Its ability to run offline as a Progressive Web App (PWA) and execute logic client-side aligns perfectly with your goals.
Key Takeaways
- Blazor Server executes C# on the server and uses SignalR to update the browser. It's fast to load, secure by default, and great for internal line-of-business applications where a constant connection is guaranteed.
- Blazor WebAssembly executes C# in the browser using WebAssembly. It has a larger initial download but enables true offline functionality, client-side processing, and easy scalability, making it ideal for public-facing SPAs, PWAs, and your kiosk application.
- The component model (
.razorfiles) is the same for both. This is a powerful feature of Blazor, meaning the skills you learn are largely transferable if you ever need to work on a Blazor Server project.
Next Lesson
Now that we have established the "what" and "why," the next lesson will move on to the "how." You will create your first Blazor WebAssembly project, and we will dissect the project structure, comparing it to the ASP.NET MVC projects you are familiar with.