Introduction to Blazor

When we create web applications, we build them on the server using languages or frameworks such as Java, .NET, Node.js, PHP, or others. Then, we present this information and interact with the user through the browser using JavaScript, either vanilla or frameworks like React or Vue.

Unfortunately, up until now, we couldn't use a backend language (.NET/Java) to modify the frontend, which deprived us of many benefits like code or library reuse.

This is where Blazor comes in.

1 - What is Blazor?

Blazor, like many other technologies, allows us to create interactive web applications, the difference is that here we do it using C#.

What this means is, now we can write C# code both on the client and the server. This is possible because the .NET runtime is compiled into WebAssembly, which runs in the browser and allows you to execute any .dll. Therefore, we can run applications written in C#.

To run WebAssembly in the browser, it's done through JavaScript (without writing a single line of JavaScript), which also gives us access to the entire JavaScript API, so we can manipulate the DOM, create websockets, use the file API, etc.

Before moving to the next point, I must point out that you don't need to install any plugins to run Blazor apps, it’s not like old Silverlight or Flash.

And since it’s C#, you can reuse libraries you have in your backend for the frontend, as long as the library is compatible with .NET Standard.

Notably, Blazor (and C#) is a strongly typed language, which helps us find errors at compile time.

A big benefit of running Blazor or WebAssembly applications in the browser is the performance, since it’s almost native. However, to execute methods like OnClick, Blazor calls JavaScript through mono.wasam, which then executes the onClick.

2 - Types of Blazor Applications

To run Blazor applications we have two options or modes:

• Blazor Server
• Blazor WebAssembly

2.1 - Blazor Server

When using Blazor Server, the entire application runs on the server. This includes all actions the user may take, like clicks, opening and closing pop-ups, etc. For the information to be smooth, it uses a file named blazor.server.js, which uses SignalR to communicate with the server.

Another thing to keep in mind is that when using Blazor Server, each user’s interaction stays in the server memory until the user closes the window.

A big benefit of running our Blazor applications on the server is that the size of the website (what the user downloads) is much smaller, allowing the application to be very fast. Debugging is much better. It also lets you run your app in older browsers that don't support WebAssembly (like Internet Explorer 6, etc.).

However, there are also drawbacks.

The obvious one is that since SignalR is used all the time, the server must always be online, and any server slowdowns will greatly affect your users.

Also, having all users in memory, it shouldn't be a huge issue. Microsoft claims you can support thousands of concurrent users with a Blazor Server app without problems.

Finally, serverless is not possible since you need ASP.NET Core running to execute the application.

2.2 - Blazor WebAssembly

Building Blazor web apps with WebAssembly enables code to run in the client’s browser. When the application starts, all files are downloaded to the browser (HTML, CSS, JS), as well as the .dll files of your C# app and the .NET runtime.

This way we convert the code to WebAssembly and browsers can natively read and understand it.

Once the app starts, it can run offline since these apps are "static files". This feature lets us create progressive web apps (PWA).

Note: Yes, you can consume APIs, we’ll see how in another video further along in the course.

Of course, just like the server version, Blazor WebAssembly has certain benefits.

The most notable is how fast it is, reaching almost-native speed by being "written" in WebAssembly.

The fact that you can work offline and as a PWA means you don’t need to be connected to the server (at least, once the app has loaded).

This version does let us deploy applications in a serverless way.

The main downside is that Blazor runs in a JavaScript sandbox and is restricted by the sandbox rules (the framework handles everything behind the scenes automatically).

The browser does all the work, this is usually a benefit, but there may be specific situations where you need heavy computational operations.

As mentioned before, Blazor WebAssembly downloads ALL the files to the browser, and all means all, which can lead to a heavier initial load, the first load will take longer.

With modern connections this isn’t a problem, but it can be with older connections.

And if the browser is very old, you CANNOT run Blazor WebAssembly, you must use Blazor Server instead.

3 - Creating a Blazor Application

To create a Blazor application, you simply create a new project and select Blazor. Once selected, you’ll be asked which type, here you should specify if you want Blazor Server or Blazor WebAssembly.

To use Blazor WebAssembly, you need to have the .NET SDK installed, with at least version 3.1.3 or newer.

Personally, I’m going to pick Blazor WebAssembly, and this project will be the frontend of the other course where we covered Web API.

When you get your project, you’ll see a structure similar to web projects in ASP, actually, the files are .razor.

Note: By default, when creating a Blazor app, you get a default structure. It also uses Bootstrap for CSS.

And if you click play in Visual Studio, you’ll see the app running.

As you’ll see in the inspector, it downloads both blazor.WebAssembly.js and the .dll files you need.

Conclusion

In this post, we’ve seen an introduction to Blazor, the differences between Blazor Server and Blazor WebAssembly, and an example of how to create a Blazor application in Visual Studio, which will be part of the "Web API" application.