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).
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#
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.