One of the questions about Blazor I’m asked most often is why it should be chosen as the front-end framework instead of more established solutions like Angular. The answer is straightforward: there are no generic reasons for adopting one framework rather than another, so you should not do it blindly! Anyway, often we look at things from a strictly functional point of view when in reality, the non-functional requirements make the difference between the success and failure of a project.
Why Angular
Angular is undoubtedly a widely used framework in the Microsoft world, probably because with the coming of .NET Core, it was clear that soon there would not be a comparable solution and because it was the closest among the frameworks in circulation to .NET developers. This happens because the Angular team, in the transition from AngularJS to Angular 2, decided to adopt TypeScript, a Microsoft tool that makes Javascript extraordinarily similar to C#.
However, we are talking about a transpiler generating JavaScript code that the browser can execute, so not a real compilator. The strictly typing offered at compile time does not exist in JavaScript and can be easily bypassed. Anyway, it is a good solution for those who deal with web front-end and want to solve the main problems of productivity and JavaScript maintenance. For those coming from the back-end, it is an excellent approach to JavaScript. And if you know C#, you almost have the illusion of a language you have always known.
Why Blazor
However, if we do not already know Angular and TypeScript, we are adding technical debt to the team. The correct use of this framework requires study and time, often even a dedicated team. The team’s knowledge and the time necessary to acquire new skills are a non-functional requirement often underestimated, which has a significant impact on projects. And here’s an excellent reason to use Blazor: you can reuse your knowledge of the .NET world in the browser, exploiting open web standards such as WebSocket and WebAssembly, downloading in the browser .NET DLLs compiled in IL (Intermediate Language) code, and running the front end of your application in the browser installed on user’s machine.
To be fair, Blazor is available in two modes, called Hosting Models: the Server version and the WebAssembly version. In the Server version, the code execution takes place on the Server-side. Changes to the user interface (the DOM in our case) are sent to the client using SignlalR, which uses WebSocket transparently to the programmer, at best. In the WebAssembly version, instead, DLLs are downloaded to the client and run thanks to a .NET runtime (the runtime of the Mono project) compiled in WASM, the binary format of the WebAssembly standard.
For a fair comparison, we must necessarily refer to Blazor WebAssembly, so that we don’t have any help from the server that Angular wouldn’t necessarily have.
From compiling to execution
Let’s start with the browser, which is the environment in which they both run, but in a completely different way. At a higher level, we can see the browser as an application that provides us with HTML and CSS to draw our interface and a whole series of APIs. Our code can interact with them to manipulate the DOM, access the available storage, communicate with the outside, and much more safely and without making any assumption on the operating system on which the browser runs.
We can access these APIs thanks to a runtime, called JavaScript Runtime, which ensures the operation of our code with all the necessary security limits in such an environment (we cannot access the file system directly, as well as peripherals, for example). The most common use of JavaScript Runtime is through JavaScript scripts, which are interpreted and executed by this runtime.
In Angular, we start from Typescript code, which is transpiled in JavaScript code, minified, and bundlerized by a bundler (typically Webpack) to serve the browser with the possible compact version of the code. This code is executed directly in the JavaScript Runtime without intermediaries, thus with the best possible performance.
In Blazor, we start from C# code compiled into IL code in a DLL assembly that is then served to the browser and the Mono runtime compiled in WASM (renamed to dotnet.wasm) and the DLL of the .NET framework needed for the application. In this case, the IL code is not executed directly in the JavaScript Runtime but loaded and executed by the Mono runtime compiled in WASM.
As we will see when talking about performance, this operating difference significantly impacts execution times, which can be one of the factors of choice between the two.
A possible comparison
To compare the two frameworks, it is necessary to have a good knowledge of both to evaluate the salient aspects in an objective and, above all, contextualized way, trying to understand when it makes sense to use one rather than the other without fanaticism.
Also, the possible plans on which to carry out a comparison are many so that we will limit the field to three specific factors. Those factors are the development experience, as the set of tools available, and how it is possible to develop applications; the functionalities made available by the two frameworks and the performances, not necessarily of pure execution, but also of waiting times of compilation and download.
Since each of these three points deserves a separate article, let’s start here with the development experience, while in the next articles we will examine functionality and performance.
Development experience
Both frameworks provide a cross-platform CLI (Command Line Interface) to create, compile, run, and deploy projects. It is possible for both of them to use paid or free editors like Visual Studio Code, for which specific plugins are available to support the development. We can also use complete Ide like Visual Studio on Windows or Visual Studio for Mac on macOS depending on our preferences or habits.
I prefer Visual Studio Code for front-end development. Still, I use Visual Studio when I deal with the development of all layers using the Microsoft stack: the development experience in the transition from front-to-frontend to back-end and vice versa is more productive with an integrated environment. In this specific case, if you develop on Windows with Blazor for the front-end and .NET for the back-end, the experience with Visual Studio is better than with Angular, given the strong integration between the products of the parent company itself. With Angular, I still prefer Visual Studio Code and its integrated terminal, the plug-ins available for Angular are many and comfortable.
Whatever environment you use, Angular’s debugging experience is more straightforward and more complete at the moment. I like to make a substantial difference between two possible debugging approaches to what we do in front-end development. The first approach sees the insertion of an interruption point in the code to examine the logic implemented and inspect the values of the variables. The second one is the one that uses the Live Reload massively, that is the automatic rebuild and refresh in the browser of the page on which you are working.
When we use the breakpoints with the browser, we have two possibilities: either to do it directly with the development tools offered by our preferred browser or to hook the browser debugger from our development environment. In both cases, it is necessary to examine the original code to understand something, then C# for Blazor and TypeScript for Angular. In the case of Blazor, however, we have a double passage involving C#, the intermediate code (IL), and its translation into WebAssembly by the Mono runtime. In Angular, instead, we pass directly from TypeScript to JavaScript, so the thing is considerably simpler. Besides, the browser has native and consolidated support for JavaScript debugging. It is not so for WebAssembly, which by the way, being a binary format potentially generatable by any high-level language, makes debugging natively difficult.
Despite all this, Blazor Webassembly offers the possibility to insert breakpoints in the code and debug the original C# code, with an overall convenient experience (much improved with .NET 5) if not done directly in the browser (exists but usability leaves something to be desired) and in any case not comparable to the Javascript.
Even with the Live Reload, I must say that the Angular CLI’s multi-browser experience is much more comfortable and stable than that provided by the .NET CLI, which was introduced in .NET 5. It happens because, in Angular, you manage to have a refresh on multiple browsers open on your application, but with Blazor you can refresh only one browser at a time. It may not seem important, but if you do cross-browser development, despite all the current standards, you often have to try your application on different browsers (sometimes even different operating systems) and may be in different modes (desktop, tablet or mobile). Nothing impossible, but it’s something to take into account. Also, in Blazor this mode works only with the debugger disabled, so you cannot have simultaneously Live Reload and breakpoints, which you have in Angular.
In all modern front-end frameworks, the interface is a set of components, so how to create a component in a specific framework becomes fundamental. Moreover, a Single Page Application is based on routing mechanisms that allow us to simulate the navigation between different logical pages since the page is physically only one: how I can instruct the routing engine is, therefore, another fundamental aspect.
From these points of view, Angular and Blazor have two completely different approaches. Angular bases its operation on an explicit statement of all parameters, so it offers a robust configurability, which, however, also means having to specify every single option other than the default. In Blazor, as in the main Microsoft web frameworks, instead, we prefer an approach more based on conventions than on configurations (Convention Over Configuration), often making more immediate the use of the framework at the expense of a more difficult configurability.
Conclusions
For the moment, we stop here, hoping to have given you some useful information to start thinking about which framework to choose for your future project. In the next articles, we will analyze the features and performance to complete the comparison and give you the main tools to make the right choice.
If you have any questions or want to chat with us about these topics, you can contact us using the form and read the other articles or watch the talk recordings about Blazor.
Happy Coding!
