Blazor. In early November 2018, when it was still an experimental product, I was talking about Blazor at an event we had organized at our office. By the way, I had surprised many colleagues when I revealed at the end that my PowerPoint presentation had been prepared with Blazor. I followed the evolution of this experiment, which became officially a product in development, until it was launched in WebAssembly version in May 2020. This was followed by a talk at Blazor Day in June, which I presented on 3 other occasions in the same year, a few episodes of the Bracket Show on the subject, plus a full-time project since last June. Oh, and I keep nagging my colleagues about how wonderful Blazor is and why there are so many benefits in using it. So I wanted to share why I think this technology is a great revolution, but without getting too technical (I’ll leave that aspect to the Bracket Show).
First, for those who don’t know Blazor at all, a brief presentation of what it is. Blazor is a framework for developing single page web applications using only C#. You can still use JavaScript, but it’s not the main language like with popular frameworks for client applications, such as Angular or React. And unlike what some people have experienced with Silverlight, no plugins are required at the browser level thanks to WebAssembly, an open web standard that allows binary code to be executed in the browser. In other words, the code compiled for our application is executed as is in the browser, it is not transformed in the same way as TypeScript, which is ultimately JavaScript when transpiled. So, we come to the question: why is it so interesting?
Is it worth learning Blazor?
The first thing I find interesting is the fact that we are working on a single programming language. I have nothing against working with different languages in the same project but working with only one language increases our productivity (when it’s a language we’re comfortable with). With Blazor, a full-stack developer doesn’t need to know multiple frameworks; if they knowsC#, MVC, ASP.NET, they already have almost everything they need to do Blazor. Of course, from a technological point of view you must keep up to date, learn new languages, try new things. I wouldn’t be here talking about Blazor if I hadn’t done it myself. However, if we consider that a framework is a bit like a toolbox and if I have the choice between bringing a single box that contains tools that I know very well, versus two boxes, one of which contains things that I know less about, my choice is going to be towards the one that gives me a better return.
Avoid mistakes with one programming language: C#
Then there is obviously the programming language, i.e., C#. On this point it’s obviously a personal preference and a business choice, however in my opinion the advantage is that it’s on the strongly typed side. With JavaScript and TypeScript (I’m mentioning these because of their common use on the web side), it’s easy to introduce errors in our applications simply with a mistake on the name of a property or variable. The error will only be noticed during the execution of the application, and it won’t always be obvious where the error comes from. And even if it is, the error should have been caught before running the application. This is where Blazor, and C#, stand out. By using a strongly typed language, you can’t make a mistake on the name of a property or variable, the application won’t compile. You can’t decide to add a property on the fly, the application won’t compile. This ensures that the application will work properly (even before we talk about unit tests to ensure that it works properly), and it saves us from having to go back to our code to correct the mistake in the word.
Avoid code duplication…again
Finally, another important point in favor of Blazor is code duplication, or rather the elimination of it. Throughout my career, which started in Windows applications with VB6, I was hammered with the idea that you should avoid duplicating code. “You should extract a function to avoid duplicating code”, “You could use polymorphism to avoid repeating code that is common to your objects”, and so on. Until the day I came across a project with the server side in C# and the client side in Angular with TypeScript. Then I started to hear sentences like this:
“For your model that your API exposes, you’re going to have to make an identical object on the client side. And don’t forget to update it when you modify it”.
“The validation must be done on the server side. On the other hand, we should also redo the same kind of thing on the client side so that the user can’t enter just anything.
So we ended up duplicating code, an action that we’ve been banning for years! It didn’t make sense in my head, and of course this kind of thing adds a risk of forgetting a change, which we’ll do again only when we try our application. With Blazor, this concern simply disappears. Blazor allows you to share libraries between the client and server side, so you can easily centralize your communication objects between client and server as well as things like validation. No need to repeat, we increase our productivity, standardize behaviors, reduce our risk of errors and especially avoid having to maintain the “same code” twice.
Blazor will change web development
I hope that this point of view on Blazor will have interested you, maybe it will even have given you the desire to try it. One thing is certain, Blazor is not just passing through, it is here to stay. Many efforts are currently underway to make it the language of choice for web, mobile and desktop applications, so if you develop using C#, the chances of you doing Blazor in the next few years are very high.
If you want to know more, don’t hesitate to read our other articles on Blazor or to discover our videos on our Youtube channel Bracket Show.
Discover also our projects as well as our custom software development services.
