Blazor is a hot framework from Microsoft that makes it possible to run .NET code directly in browser on top of WebAssembly. And it is no longer an experimental project it used to be. It has officially made its way into .NET Core 3.
The ability to run compiled code directly inside the browser is useful. However, plain old JavaScript is sometimes a better solution.
And there are also different types of Blazor, which are suited to different scenarios. Therefore, whether or not to use Blazor in your web application, may not be a simple decision.
But not to worry. We will now examine pros and cons of Blazor compared to its alternatives. Likewise, we will have a look at different types of Blazor and will examine pros and cons of each compared to each other.
By the end of this article, you will be well equipped to decide whether Blazor is the right solution for you.
Different Blazor types
Although Blazor has originally started as an experimental technology that runs .NET code inside a web browser, it has since evolved into two district types, only one of which, what came to be known as client-side Blazor, runs in the browser. The other variety, server-side Blazor, runs the same kind of code, but it runs it on the server.
So, why are these two types needed? Here is how they came about and what they do.
Client-side Blazor
This is the original Blazor that has evolved from the experimental project. Since then, the status of the framework has been upgraded from experimental to preview. So, it is kind of OK to use it in production.
Just as before, Blazor runs inside of .NET runtime on top of WebAssembly, so the compiled code runs directly in the browser.
Server-side Blazor
Back in the days when the original Blazor was an experimental project, Microsoft decided to incorporate Blazor functionality into the upcoming major version of .NET Core. However, since Blazor was based on an experimental technology and was running on top of a new and unproven platform, it was too risky to include it in .NET Core as is.
Instead, Microsoft decided to add another technology with programming syntax almost identical to Blazor. This is how Razor Components were born.
Unlike the original Blazor, Razor Components ran all of their logic on the server. However, the server-side code was communicating with the client-side code in real time using SignalR.
When the preview 5 of .NET Core 3 came out, the original Blazor project was deemed to be worthy to get it’s status upgraded from a mere experimental technology to preview. At the same time, Microsoft has decided to rename Razor Components to server-side Blazor and change its project structure, so it matches the project structure of client-side Blazor, what the original Blazor project was then renamed to.
So, if you look at the code of any of these project types and how the folders and namespaces are organised within them, two types of Blazor are almost identical. The only code that is different is the application startup code. This means that the code of server-side Blazor can be copied and pasted into client-side Blazor project and vice versa.
Each type of Blazor has its own pros and cons. Let’s examine them.
Pros of client-side Blazor
1. Running .NET code directly in browser
This was the unique selling point of the original Blazor project. You can compile your .NET applications and run them in Browser.
Until recently, Node.js had a monopoly on allowing you to be a full stack developer without being a programming language polyglot. The same JavaScript you would normally run on the client could now be run on the server.
Until WebAssembly came out, JavaScript was de-facto standard language for any in-browser logic. So, if you were a back-end .NET developer, you had no choice but to learn JavaScript in order to become a full stack ASP.NET developer.
With client-side Blazor, you no longer have to learn JavaScript. Everything in the browser can be done in C#.
2. Faster than JavaScript
Client-side Blazor is currently pre-compiled into intermediary language before it’s downloaded into browser and, as it development progresses, it will eventually be fully pre-compiled into WebAssembly.
Due to its compiled nature, it would probably be a lot faster than the equivalent logic from JavaScript. While it won’t make much visible difference for simple calculations, it will provide a tremendous benefit for performance-intensive applications.
So, if you can run compiled code in your browser, you can make many applications that aren’t even possible to be made in JavaScript, such as video games that rival the ones on premium gaming consoles or augmented reality apps.
3. The same validation code can be applied on the client and on the server
Quite often, you need to apply the same validation on the server as you would on the client. For example, you may tell user that the password is written in an invalid format straight after they would enter it, which will save them a round trip to the server. But you may then do the same validation on the server, just in case the request to the server has bypassed the client validation.
With Blazor, you can just write a class library with shared functionality. You can then add this library as a reference to both your Blazor app and your server-side application.
This way, although the logic will still be executed in two places, it will be the same bit of code that runs in them both.
4. Works offline
Unlike server-side Blazor, client-side Blazor doesn’t require to pass data to the server with every single action. Therefore, there will be far less network bandwidth used.
Likewise, if the network access is temporarily down, your app will still work. You may even have an app that is designed to be completely independent from the internet once you’ve downloaded it. This would be the perfect way of building such an app.
Cons of client-side Blazor
1. Requires the whole runtime to be shipped
One major disadvantage of client-side Blazor compared to both server-side Blazor and JavaScript is that the download size of client-side components will be way bigger than for any of them.
This is because Blazor doesn’t merely compile into WebAssembly. Only it’s runtime is compiled into WebAssembly, while the actual application requires this runtime to run.
Runtime may be the biggest part of the download, so even a basic application with just a couple lines of code is guaranteed to be quite a few megabytes in size.
2. Doesn’t work with thin clients
WebAssembly is designed to work with all major browsers. While this is fine for most of the web users, there are use cases where you have to access the web from a non-standard browser. And some of those won’t have WebAssembly.
While it is possible to use some polyfils to enable Blazor to work on browsers that don’t have WebAssembly, this approach is not recommended. You will lose many performance benefits of Blazor and will substantially increase the download size, so using it will almost be pointless.
3. Limited debugging capability and .NET tooling
Client-side Blazor has its own debugging tab in the browser and this is, pretty much, the only way to debug it.
The problem with it is that debugging capabilities in this custom-made tab are very limited. So, for the apps with complex logic, you may have to place a huge amount of logging in order to debug some of the code. Or you may be forced to write your initial prototype as a server-side Blazor app if there is a bug in your code that is hard to track.
Pros of server-side Blazor
1. Is fully compatible with any .NET libraries and .NET tooling
Unlike client-side Blazor that comes with an incomplete debugging capabilities, server-side Blazor can be debugged in exactly the same way as any other ASP.NET application. Because it is, essentially, an ASP.NET Core application.
Likewise, all other standard tools you can use with any other types of.NET applications can be used with server-side Blazor.
2. Uses exactly the same syntax as the client-side Blazor
So, while server-side Blazor may not be the best choice for certain scenarios where client-side Blazor is useful, you can still initially write your app as server-side Blazor project to overcome the limited debugging capabilities of client-side Blazor.
Once your application is release-ready, you can just copy and paste your code into a client-side Blazor project.
Likewise, the same syntax allows you to write a class library that will work with either client- or server-side Blazor.
3. Small size of client-side components
When it comes to downloading client-side components of server-side Blazor, those will only include a relatively small amount of HTML and JavaScript, neither of which necessary has to be written by yourself.
All the heavy lifting is done on the server, so the client-side download is significantly smaller.
4. Works with thin clients
Server-side Blazor doesn’t care what kind of browser you have. Client only gets bog-standard HTML and JavaScript that work virtually everywhere. Therefore server-side Blazor will be compatible with pretty much any client you can think of.
Cons of server-side Blazor
1. Does not have performance benefits of the client-side version
Of course, as server-side Blazor routes every single action to the server, the action will be delayed by the network latency. And it will use more bandwidth.
With this in mind, server-side Blazor is likely to be slower than even the conventional JavaScript, so the applications need to be designed in such a way where only the most performance-hungry actions are delegated to be done by the server.
2. .NET server is required
Client-side Blazor ships with its own runtime. Server-side Blazor, on the other hand, only runs as a part of .NET application. Therefore .NET runtime is required to be pre-installed on the server.
3. Reduced scalability
Because server-side Blazor uses SignalR, there is a limit to how many simultaneous connections can be handled from the clients. So some effort would be required to scale the application out.
Some examples of how to scale a SingnalR application are taught in this course and similar principles will apply to a server-side Blazor application.
Client-side Blazor, on the other hand, doesn’t have this problem at all. Each client runs a self-contained instance of the app, so it can be scaled indefinitely.
Blazor alternatives
While Blazor is currently the easiest way of placing your .NET code into the browser, there are some alternatives. So, if you want to place your C# code into WebAssembly or interact with your web page components from the server, you can try any of the following.
Lara
Lara is a framework that allows you to manipulate DOM components of a web page from the server.
It is similar to server-side Blazor, but is much more lightweight and easier to install. For example, while any type of Blazor requires a whole SDK, Lara is just a NuGet package.
For more information on Lara, you can visit its official GitHub page.
Mono
Blazor relies on mono as its WebAssembly environment. This is because mono comes with in-built support for WebAssembly compilation.
So, if you think that Blazor is not suitable for a specific task you are trying to achieve, you can write your own mono framework for placing your code into WebAssembly. Or you may be able to find other examples from people who have already done so.
To find out more about WebAssembly support on mono, you can visit this page.
Summary
In this articles we saw what benefits Blazor provides and what limitations it comes with.
As there are two distinct types of Blazor, each one of them comes with its own set of pros and cons, which may either make them complimentary, or mutually exclusive, depending on a particular problem you are trying to solve.
While client-side Blazor is faster that either JavaScript or server-side Blazor, it requires its whole environment to be downloaded, which may be quite hefty. Server-side Blazor, on the other hand, requires very little in terms of client-side download, while it’s not suitable for the apps where the performance of in-browser components is critical.
If you would would want to learn how to use both client-side and server-side Blazor, this Udemy course would help you. For more technology courses that I have published, have a look at this page.
Happy hacking!
