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