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.
To explore all the articles from this series, you can visit our Blazor WebAssembly Series Page.
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 bite code. The .NET runtime runs into the browser and it 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 is 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 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
- 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 and it is 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 all the time to the server, so, no offline support. Each interaction must go to the server which can cause network delays. Scalability can be challenging 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, 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 said, the Blazor WebAssembly can work in the offline mode, which means it doesn’t require 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 our application requires some hard processing actions, 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 a longer time to load the application. 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 have to create both of them. So, let’s do that.
The creation process is the same as for any other ASP.NET Core application. We have to create a new Blazor App project:
Name it, and finally, 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.
Pay attention, if you don’t have the Blazor WebAssembly App project, you have to install the required .NET Core SDK (version 3.1.3 or later)
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. So, this is very small, but if we take a look at the console window, we are going to find a true size of downloaded files. So, if you ask why is this difference, the answer is in the cached files. The Blazor WebAssembly caches files for the faster application load. We can see that in the Application tab, under the Cache section:
This helps a lot for the application to loads faster.
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.