Has the moment arrived for us to relegate Angular to the past and unanimously transition to Blazor? Or perhaps, could it be that Blazor, as the successor to Razor, is afflicted from the same issues as its predecessor? In light of the recent opportunity that arose within our company to initiate a project from the ground up, utilizing Blazor, this article aims to explore the insights gained during this process
Furthermore, an attempt will be made to capture the present state of this framework and compare its advantages and flaws to already mentioned Angular.Could it be that the moment has arrived to contemplate a shift in our company's primary front-end framework? And, perhaps, even in yours?
Blazor is an innovative and powerful web framework that has been making waves in the world of web development. But what exactly is it, and why should you be interested in it?
So, why should you consider diving into Blazor?
In essence, Blazor is a game-changer in web development, offering a fresh perspective on how we build web applications. Whether you're a seasoned .NET developer or looking to expand your skill set, exploring Blazor is a worthwhile endeavor that can open up exciting possibilities in your web development journey.
Before diving into the world of Blazor, let me give you a glimpse of my background and experience. I approach it as a full-stack developer with a primary focus on .NET and past experience with Angular, along with a brief encounter with Razor.
My initial encounter with this technology began with searching for and taking an appropriate course on the Pluralsight platform. This allowed me to get a preliminary understanding of the basics and the concept of writing frontend code within this framework, without delving deep into dry documentation.
It quickly became apparent that Blazor and Angular had quite a bit in common, which greatly facilitated my journey into working on my first project using this technology. The plan was straightforward: create a foundational web service project with standard features like registration, login, translations, and more.
The intention behind this project was to learn the basics while creating something that could in the future serve as a foundation for more personalized and complex endeavors. This way, I could build upon the groundwork laid by this initial project to develop more customized and intricate applications down the line.
So, it was time to start laying down the architecture. The first crucial decision I had to make was how I wanted to host my application since Blazor offers three different methods: Server, WebAssembly, and Hybrid. Each approach comes with its own set of advantages and disadvantages, making it crucial to choose the one that aligns with your project's specific requirements.
In summary, the choice of hosting for your Blazor application should be guided by your project's needs. Server hosting excels in real-time communication but may face scalability challenges. WebAssembly hosting offers client-side execution and offline capabilities but may have a larger initial load time. Hybrid hosting provides flexibility but requires careful architecture planning. Understanding the trade-offs and aligning your choice with your project's goals is key to a successful Blazor application deployment.
Following some brief consultations, I made the decision to host the Blazor (server) frontend within the .NetCore API. This choice came with several distinct advantages, as outlined earlier, and it streamlined project management by consolidating everything into a single solution hosted on a single Azure App Service.
The architecture creation phase went smoothly. I quickly assembled the frontend using a user-friendly wizard, and setting up the connection between the frontend and the API to ensure it displayed seamlessly upon launching the API project was a breeze, requiring just a few additional lines of code here and there.
This effortless integration exemplified the ease and efficiency of working with this architecture, setting the stage for the next phases of development with confidence and excitement.
With a functional project in place, it's time to delve into the Blazor approach to defining views. In my opinion, this approach strikes a balance between Razor and Angular. We have the HTML portion (.razor) where we define the page's appearance, either using plain HTML or, as in my case, utilizing an external component library (Radzen). This part also allows for writing logic, but, in my view, it might not be the most convenient or readable approach. An alternative is to extract the logic into a separate file (.radzen.cs), where we can comfortably write C# code so that is what I did.
Although I had never written in Blazor before, I quickly found my way around this framework. Two simple inputs, a button, and an injected service for API requests, and the front-end part of the login was complete. This is what I like most about this technology. Having an idea of how to do something in Angular, it's very easy to do it here as well.
Things went smoothly from there – I quickly set up a responsive menu for easy navigation between pages, implemented user registration with policy handling (using Microsoft.AspNetCore.Authorization), and of course, token management with JWT (JSON Web Tokens). I found great help in the built-in ILocalStorageService (Blazored.LocalStorage), which functions very similarly to Angular's local storage.
The only major challenge I encountered was implementing multilingual support for the interface. I wanted it to be dynamic and editable within the application itself, which meant that standard solutions based on resource files in the API didn't quite meet my requirements. Here, unfortunately, I faced the main drawback of Blazor – it's a relatively new technology. When you want to do something unconventional, there's a good chance there aren't thousands of Stack Overflow questions about exactly what you want to achieve, and you have to figure it out on your own. In this regard, Angular's maturity and extensive community support do work in its favor.
Ultimately, I had to build multilingual functionality from scratch, similar to Angular's ngx-translate, by dynamically creating JSON files for translations from a database.
Setting aside smaller functionalities like user,language and translation management, that's where my journey with Blazor came to an end.
What are my conclusions? Well, Blazor is certainly an intriguing technology, and with time and an increasing user base, it will become more accessible, especially if you already have experience with Angular or Razor.
Here, I'd like to present to you a few advantages and disadvantages of both technologies.
In conclusion, both Blazor and Angular have their own strengths and weaknesses. The choice between them depends on your project's specific requirements, your team's skillset, and your development preferences.
In conclusion, Blazor and Angular are two powerful web development frameworks, each with its own set of advantages and disadvantages. Blazor, with its .NET integration, offers familiarity to .NET developers, component-based architecture, and the flexibility of running code either on the server or in the browser. On the other hand, Angular boasts a mature ecosystem, robust features, strong TypeScript support, and scalability for large applications.
The choice between Blazor and Angular ultimately depends on your project's specific requirements and your team's familiarity with the technologies. Whether you opt for the innovation of Blazor or the established capabilities of Angular, both frameworks have the potential to help you create exceptional web applications.
As the web development landscape continues to evolve, staying informed about these frameworks is essential for making informed decisions that will shape the future of your projects.