But, we can’t use the language we used for the server-side application in the client-side application. So, there is a fundamental disconnect between these two.
So, wouldn’t it be great if we could use the same language for the server and client-side applications and reuse our knowledge? Well, we believe it would. We can achieve that by using WebAssembly. It is a native part of all the major browsers and it allows us to reuse our code from the server-side applications.
But before we continue, let’s take a look at the complete navigation for this article:
- What is Blazor and Why Should we Use It?
- Different Models of Blazor Applications
- Differences Between the Blazor Server and Blazor WebAssembly Applications
What is Blazor and Why Should we Use It?
Blazor is a free and open-source framework that allows us to build interactive web applications using C#. So, we can use C# to write both server and client code in Blazor. We achieve that by having .NET runtime compiled into the WebAssembly bytecode. The .NET runtime executes in the browser and can run any .NET DLL we provide to it, including C# code that we create with our Blazor applications.
So, this is one of the reasons to use Blazor.
But there are more.
With the Blazor WebAssembly, we can run our applications in many major browsers without additional plugins. Furthermore, we can use any library we want, as long as it is compatible with the .NET standard. This means we can use the libraries we created and a large number of NuGet packages as well.
Of course, performance plays a great role in choosing a framework for web development. That said, the ability to run Blazor in WebAssembly only proves the fact that it is pretty fast at almost native speed.
Different Models of Blazor Applications
So, as we already mentioned, there are two different models of Blazor applications:
- The Blazor Server Application
- And the Blazor WebAssembly
Let’s explain a server-side Blazor first.
Because server-side application remains in the memory all the time, the instance is created per user while the client-server interaction is happening.
So, the benefit of this type of application is that the download size is really small, significantly smaller than the Blazor WebAssembly, which means the application loads much faster. Because it runs on the server-side, it uses all the advantages of server capabilities with all the server-side APIs available. Additionally, we have full debugging support and our application can work on the browsers that don’t support WebAssembly. This means, older browsers are supported.
Of course, there are some downsides.
Since it runs on the server, it must be connected to the server all the time, so there’s no offline support. Each interaction must go to the server which can cause network delays. Scalability can be a challenge because an application instance is created per user. But this shouldn’t be that much of a problem because the server-side app should support thousands of concurrent users (information from the Microsoft developers).
Finally, serverless deployment isn’t possible. ASP.NET Core server is required to serve the app.
So, once the application starts, it can work in offline mode, meaning, it doesn’t require the server. Because this type of application is composed of static files, we can deploy it to the CDN or Server or Azure Storage for static websites.
So, as with the server-side Blazor application, the Blazor WebAssembly has its benefits and downsides.
The first benefit is that this type of application is very fast, with the speed almost as the native browser applications. As we’ve said, the Blazor WebAssembly can work in the offline mode, which means it doesn’t require a connection to the server.
Additionally, serverless deployment is possible, which means you don’t need a server, just something to get the files to the browser. Finally, this type of application can run in all modern browsers without additional plugins. This makes deployment easy on all sorts of devices.
Since this type of application runs only in the browser, it is restricted to the browser’s capabilities. Another thing is that everything executes in the browser. This could be a downside if the application does some heavy lifting, and our browser may not have enough resources to support that.
An additional downside is that Blazor WebAssembly downloads all the files to the client, meaning loading times are longer. Finally, because the WebAssembly is required to run this type of application, older browsers (without the WebAssembly support) can’t run the Blazor WebAssembly applications. That said if our application requires running on an older browser than it is a better choice to use the Blazor server-side application.
Differences Between the Blazor Server and Blazor WebAssembly Applications
To show the differences between these two application types, we are going to create both of them.
The creation process is the same as for any other ASP.NET Core application. Let’s create a new Blazor App project first:
Name it and choose what project type we want to work with:
For the first application, we are going to choose the Blazor Server App, and for the second, we are going to choose the Blazor WebAssembly App.
Now, let’s open both applications and inspect the differences.
If we inspect the
wwwroot folders of both applications, we can see that the WebAssembly application has the
index.html file which doesn’t exist in the server-side app:
This file contains the reference to the
blazor.webassebly.js file that is responsible for downloading all of the application’s assets. This .js file also initiates the runtime to start the application.
A similar thing happens on the server-side application in the
This file references the
blazor.server.js file (which we talked about), and it establishes the client WebSocket connection to the server.
If we inspect the
Pages folder of both projects, we can see they have the same files (FetchData, Index, Counter). This means we can reuse our component files from one to another project without any problem.
Now, if we again pay attention to the
Solution Explorer window of both projects, we can notice that the server-side application contains the
appsettings files. We can’t find these files in the client-side app. So to register services in the Blazor WebAssembly application, we are going to use the
Program.cs file (we will see how later in the series).
Download Files Inspection
Finally, let’s run the server-side application and inspect the downloaded files:
We can see what files it downloads while starting.
Now, let’s run and inspect the client application:
And, we can see few files as well with a size of 125 KB. This is very nice, but if we take a look at the console window, we are going to find a true size of downloaded files.
So why is this different, can you tell?
The answer lies in the cached files. Blazor WebAssembly caches files for the faster application load. We can see that in the Application tab, under the Cache section:
This helps improve the application load time a lot.
So, that is all for this introduction part of the Blazor series.
You have learned about Blazor, about different hosting models, and what are the differences between them. With this knowledge, we are ready to dive into the project and get some practical knowledge.
That said, in the next article, we are going to learn about the Blazor components, different ways to use parameters in the application, and how to debug the Blazor WASM application.
Well, see you there.