Hosting Models

In this hosting model, the web app is executed on the server and only updates to the UI are sent to the client's browser. The browser is treated as a thin client and all of the processing occurs on the server. When using Blazor Server, UI updates, event handling, and JavaScript calls are all handled over an ASP.NET Core SignalR connection.

Note: SignalR is a software library that allows the web server to push real-time notifications to the browser. Blazor Server uses it to send UI updates to the browser.

Advantages of Blazor Server

There are a few advantages of using Blazor Server vs. using Blazor WebAssembly. However, the key advantage is that everything happens on the server. Since the web app runs on the server, it has access to everything on the server. As a result, security and data access are simplified. Also, since everything happens on the server, the assemblies (DLLs) that contain the web app's code remain on the server.

Another advantage of using Blazer Server is that it can run on thin clients and older browsers, such as Internet Explorer, that do not support WebAssembly.

Finally, the initial load time for the first use of a web app that is using Blazor Server can be much less than that of a web app that is using Blazor WebAssembly because there are fewer files to download.

Disadvantages of Blazor Server

The Blazor Server hosting model has a number of disadvantages vs. Blazor WebAssembly due to the fact that the browser must maintain a constant connection to the server. Since there is no offline support, every single user interaction requires a network roundtrip. As a result of all of these roundtrips, Blazor Server web apps have higher latency than Blazor WebAssembly web apps and can feel sluggish.

Tip: Latency is the time between the UI action and the time when the UI is updated.

Another disadvantage of using Blazor Sever is that it relies on SignalR for every single UI update. Microsoft's support for SignalR has been improving, but it can be challenging to scale.

Finally, a Blazor Server web app must be served from an ASP.NET Core server.

In this hosting model, the web app is executed on the browser. In order for both the web app and the .NET runtime to run on the browser, the browser must support WebAssembly. WebAssembly is a web standard supported by all modern browsers, including mobile browsers. While Blazor WebAssembly itself does not require a server, the web app may require one for data access and authentication.

In the past, the only way to run C# code on the browser was to use a plugin, such as Silverlight. Silverlight was a free browser plugin provided by Microsoft. It was very popular until Apple decided to disallow the use of a browser plugin on iOS. As a result of Apple's decision, Silverlight was abandoned by Microsoft. Blazor does not rely on plugins or recompiling the code into other languages. Instead, it is based on open web standards and is supported by all modern browsers, including mobile browsers.

Advantages of Blazor WebAssembly

Blazor WebAssembly has many advantages. First of all, since it runs on the browser, it relies on client resources instead of server resources. Therefore, unlike Blazor Server, there is no latency due to each UI interaction requiring a roundtrip to the server.

Blazor WebAssembly can be used to create a Progressive Web App (PWA). A PWA is a web app that looks and feels like a native application. They provide offline functionality, background activity, native API layers, and push notifications. They can even be listed in the various app stores. By configuring our Blazor WebAssembly app as a PWA, our app can reach anyone, anywhere, on any device with a single code base.

Finally, a Blazor WebAssembly web app does not rely on an ASP.NET Core server. In fact, it is possible to deploy a Blazor WebAssembly web app without a server.

Disadvantages of Blazor WebAssembly

To be fair, there are some disadvantages to using Blazor WebAssembly that should be considered. For starters, when using Blazor WebAssembly, the .NET runtime, the dotnet.wasm file, and our assemblies all need to be downloaded to the browser for our web app to work. Therefore, a Blazor WebAssembly application usually takes longer to initially load than a Blazor Server application. However, there are strategies, such as deferring the loading of some of the assemblies until they are needed, designed to speed up the load time of the application.

When debugging a Blazor Server application, we can use the standard .NET debugger. However, to debug a Blazor WebAssembly application, we need to use the browser's debugger. To enable the browser's debugger, we need to launch the browser with remote debugging enabled and then use “Alt+Shift+D” to initiate a proxy component that sits between the browser and the editor. Unfortunately, due to the complexities concerning debugging on the browser, there are certain scenarios, such as hitting breakpoints before the debug proxy is running and breaking on unhandled exceptions, that the debugger currently can't handle. Microsoft is actively working on improving the debugging experience.

Another disadvantage of Blazor WebAssembly web apps is that they are only as powerful as the browser that they run on. Therefore, thin clients are not supported. Blazor WebAssembly can only run on a browser that supports WebAssembly. Luckily, due to a significant amount of coordination between the World Wide Web Consortium (W3C) and engineers from Apple, Google, Microsoft, and Mozilla, all modern browsers support WebAssembly.

The Blazor framework provides two different hosting models, Blazor Server and Blazor WebAssembly. A Blazor Server web app runs on the server and uses SignalR to serve the HTML to the browser. Conversely, a Blazor WebAssembly web app runs directly in the browser. They each have their advantages and disadvantages. However, if we want to create responsive, native-like web apps that can work offline, we need to use Blazor WebAssembly.