What does Blazor mean for application developers and businesses?
Now, having some knowledge of what Blazor is from previous articles: part I & part II, we could look at what it means for both businesses and developers.
Let’s clarify one thing from the top. Blazor was not introduced to replace all other web frameworks. Like any competition on the market, new players force everyone to grow and advance in technology. That’s a good thing. The conversation is then not which framework is the best but rather which one is best for your environment and to solve your problem. Me, being me, might sway a whole argument in favour of Blazor though.
It’s all about perspective
When you’re making any decision about software development technicalities, you always weigh out the pros and cons of your next step. Depending on where you are in life, those choices can be drastically different, even though they might come down to the same problem. Different needs, different perspectives.
It’s no different in an agile software development environment. Business folks and software developers all strive for the same goal but often do not see eye to eye. One’s empirical, the other – technical. It all comes down to understanding both perspectives.
By the way, recently, my buddy Sebastian published an article “How to work with software developers? Real-life business tips to improve your cooperation” on our blog. He highlights challenges and remedies to cooperation between businesses and developers. These are actionable real-life points to improve your workflow, so don’t forget to check that out.
Now here we come, with a scale of pros and pros (yes, that’s correct) of Blazor development already made for you. As usual, it comes down to perspective. Consider them just guidelines and adjust to your use cases.
From business perspective
The time when .NET was optimal and available only in the backend has passed. Blazor allows any .NET developer to become an end-to-end, full-stack product deliverer. This wide-spreading inclusion means a rapid growth not only for new technology but also of the quality of products that it can support.
Having the ability to write an entire application in one code stack greatly decreases its complexity. That’s not only in terms of the codebase itself but also required infrastructure. This, in turn, lowers the costs of maintenance and deployment. With a shorter development cycle, teams would be achieving application stages quicker. It means more efficient and more predictable project deliveries, so you as a business could focus on your client needs, not a missed deadline.
No matter if you already have a .NET development team or you’re looking to outsource one, choosing Blazor for your solution will positively impact their performance. Communication frictions would be limited, as both backend and frontend teams speak the same coding language and follow common principles. Integration between those parts should then be almost seamless.
And here’s the deal-making point. Blazor is much more than a web framework. Its components (the base development unit) are completely independent of the hosting environment. This means you can move from having just a web application to offering a native mobile version or even an IoT solution at any point in time. To say more – in all those environments, your application will look and behave the same way, giving the same experience to all its users, no matter the platform.
The one thing you need to keep in mind, though, is the fact that Blazor is a fairly young technology. Even with its rapidly growing community and wide adoption, it’s a challenge to find experts who can support your vision and deliver a good quality product. I’ll shamelessly plug #Inspeeriteam here. Why don’t we analyze your problem and together find the path to making it work? Especially with Blazor.
From (.NET) developer perspective
Wherever you look for information about Blazor, the first thing mentioned is that it’s a remedy to TypeScript or JavaScript struggles. And in the majority of cases, that’s true. You can write a C# code next to your HTML and make it interactable. In other cases, you can probably find and adapt existing IJSRuntime extensions on GitHub and still avoid working directly with script files.
Furthermore, Blazor’s main premise is componentization. Components are just classes on steroids where steroids are HTML and CSS markups. Those classes can be ported to any solution you need them in. When you finally build up your library, it will come down to the backend logic implementation and making a puzzle of components you already have.
How does then interactivity happen? In the simplest way, of course. Whenever an @ symbol is used within an HTML markup, it’s no longer a markup but a C# code. With that, using the @bind parameter binds a UI element value to a C# data type. On top of that, @bind:event allows specifying when exactly that binding should happen. OnClick? OnChange? OnFocus? That’s all within the component.
How then communication between different components works? Well, that depends on the complexity of your solution. Out of the box, you should just use a parameter type called EventCallback. It allows delegating behaviour to a method passed in from a parent component. For more complex portal applications, I highly recommend the implementation of a hub and spoke pattern to avoid tight coupling.
When it comes to error handling, it can always be a challenge. In .NET 6 a component was baked in Blazor itself to solve that for you (yes, if stuff makes sense, it is provided for everyone). ErrorBoundry will not only listen for exceptions but also grab them when thrown and display a user-friendly alert rather than crashing your whole app. Those alerts are also fully customizable.
Last but not least – what about testability? First – there’s a huge value in testing your code, so you should be implementing that. Second – a unit testing framework was built especially for Blazor – it’s named bUnit. It doesn’t require having your entire application context to be built when you run your tests. Running in a unit-testing fashion, it’s as quick but much more profiled to handle components testing.
We will probably have a separate article, or a couple, just on testing Blazor applications. As a teaser though, let me mention that it introduces an assertion MarkupMatches(). This validates a markup generated by the component – a simple concept. What’s wild is that it doesn’t care about CSS classes or HTML tags order. As long as the expected behaviour and look are met, the test will pass almost like a markup context check rather than a value comparison.
Let’s summarize
If, as a business, you still hesitate to make use of all that Blazor thing, I highly encourage you to let us know. We’re experienced in onboarding clients to the idea and most importantly, delivering reliable results.
If, as a developer, you’re still hesitant to try out frontend development, I highly recommend that you give it a try. You’ll learn a lot in the process. You’ll increase your value. Well, you might even like it at the end.
If, as a blog reader, you want to learn more about Blazor, you’re in the right place. Don’t leave. The party is just getting started.
Get ready for technicalities!
Starting from the next post, we’re gonna jump into some technical Blazor matters. It took some time, I know, but we needed this introduction first. Recently, I appreciated that making good architecture decisions at the beginning makes the rest of the development process an easier flow. I also found myself surrounded by specialists in architect matters.
With that said, we are going to kick off the tech part with an architect point of view:
- best practices in structuring your Blazor solutions
- principles to follow while building Blazor applications
- keeping a clean codebase and components refactoring
Follow! Stay tuned! And see you soon!
