Blazor is amazing. This technology allows .net developers to leverage their hard-earned skills to develop amazing web applications without learning a new language or struggle with the big old javascript troll. I was interviewing for a job when Blazor was first released as an experiment and the architect who was running the selection process told me that Blazor will never get a released version and that it will die out as quickly as Silverlight. Well, Silverlight actually didn’t die out quickly but had quite a carreer.
Some Blazor detractors keep saying that this technology is only a fancy version of Silverlight. That is wrong. Silverlight was xaml and c# running in the browser with the help of an installed plug-in, while Blazor is c# and html running in your browser without the help of any plug-in.
As it is new, I know that not a lot of people are using it, but the community is very active behind it and when Telerik released a full set of controls for Blazor, you know they won’t dedicate resources to something they wouldn’t trust and given the enthusiastic reponse Blazor received from the .net developer community, I can safely say it is here to stay.
Now for those of you who don’t know what Blazor is, a word of explanation. Blazor can be summarised as .net code running in the browser using two different technologies, server-side (using SignalR) and client-side (using Web Assembly). If you are wondering what SignalR be, you can check it our here, there’s a lot of explanation and it’s a good starting point.
I will try to explain in this post both sides of Blazor so it can help you all start up with this amazing technology.
What is Blazor
Blazor was first introduced in NDC Oslo in 2017 by Steve Sanderson. It was only a 10 minutes section in his presentation that lasted a full hour. Now, what he presented wasn’t very big, but it was significant. You can find the video here where he starts talking about .net in the browser, it’s inspiring to say the least. The reaction of the audience was particularly pleasing.
Blazor Web Assembly
Web Assembly can be decribed as a kind of small virtual machine that allows your code to safely run in sandbox mode in your browser. It is supported by Firefox, Chrome, Edge and Safari. As it is natively supported you do not need a plug-in for it to run, which makes it much easier to deploy.
The Blazor runtime is written using Mono, which is a reverse-engineered .net runtime that is the first that could run .net code in other platforms than Windows. Mono is very interesting in that it is also what is behind Xamarin (that you use when you want to develop mobile applications for Android and IOS using .net)
When running a Blazor Web Assembly application, dlls are first downloaded by your browser. A small javascript bootstrapper code is executed to launch the Web Assembly runtime and the actual Blazor code is launched. Blazor is not javascript code generated from c# code. The Web Assembly runtime actually runs the c# code you wrote.
The biggest advantage beside writing a rich web app using c# is that the application runs on your browser, so on your machine. There are no page refresh needed and the only Client-Server Communications needed are the ones the app needs to fetch data and so on. You do not need an internet connection when you application is downloaded for it to run.
The main downside is that when you first open the application, it can take some time to open due to download, so you might want to check the size of your assemblies.
Blazor Server Side
Blazor Server-Side was the first version of Blazor to be released. It leverages SignalR to make the application rich and interactive without needing a page refresh. Your application is also bootstrapped using a small Javascript code that will launch the SignalR client. This means that there will be a secure open channel between the client and the server that is needed for it to work.
Now, there will be a few dlls needed for the application to run, but your entire application will not be downloaded. Only the bits and pieces that the SignalR client will need to open a channel with the SignalR hub to make your application running. So a great advantage of this is that the first run of the application will be fast but the actual launch of the application might be slow depending on your internet connection. This means the Blazor Server-Side application cannot run without an internet connection.
As Blazor Server-Side does not use Web Assembly, it can run on browsers that do not support the technology yet, and SignalR can run on quite old browsers as it uses either web socket or long polling to work, so you do not need to worry about how you call your server.
So which one do we want to use?
That will mainly depend on your application. There are different scenarios we can think of but few will exclude one side or the other.
I would recommend though as a rule of thumb that if your application is big and you have a lot of client-server interactions, then you might want to use Blazor Server-Side. On the other hand, if your application isn’t very heavy and downloads itself quite fast then Web Assembly is the way to go.
A very big and important point is that you don’t code differently wether you use Server-Side or Web Assembly Blazor. Only a few changes would be required and none would be needed in the code that runs in your pages.
Happy Coding !