Blazor: Five reasons to use .NET for your front end development
You now have two different tech stacks, two different sets of skills, two different ways of deploying and maintaining code, very probably two different swimlanes in your project management board, and maybe even two distinct teams or sub-teams, one to handle each end. Wouldn’t it be better to rationalise your tech stack and increase your productivity by using one single team and one single language for both your front end and back end?
5. Your company is already C# focused
You already have invested in a .NET stack and architecture. Your team is staffed with C# developers. You have the tools you need to deploy and manage your code easily. You know this way of working is a solid, reliable foundation for your product.
But when it comes to front end development, it might seem like you have few options. You can outsource your web interface. Or you can hire front end developers who won’t be able to work on the core back end services of your product. Or you can have a few of your developers doing the front end on the side.
Wouldn’t it be much better to be able to handle the front end and the back end with the same tech stack, the same language, the same libraries - and the same developers?
Enter Microsoft Blazor.
3. Blazor is here to help
There are two flavours of Blazor. One, Blazor Server, runs all the logic on the server, in the usual ASP.NET way. The version we’ve been waiting for, though, is Blazor WebAssembly, in which Single-Page-Apps (SPAs) written in .NET can run directly in the client browser. And that’s where things get very interesting.
In Blazor WebAssembly, both the client and the server code are written in .NET, allowing you to share code and libraries between both sides. Because it’s .NET code at both ends, you can reuse your existing server-side code and your existing libraries to create the client-side part of your application. So Blazor allows you to build reusable web UIs, on a stable platform, using .NET end-to-end.
Blazor is also flexible. First, as we mentioned, there’s an option for Blazor to run all the logic on the server side if needed. Second, Blazor WebAssembly gives you a choice of languages to choose from, so it doesn’t require you to only use C# on the server side (anyone for F#)? In fact, you don’t even need to use .NET on the server side at all! If you already have a legacy back end written with PHP, Rails, or anything else, you can still write .NET client side code to run against it. Pretty neat, uh?
So you can see that if you’re a C# focused organization, Blazor represents a huge opportunity to expand out into front end development, and rationalise your tech stack.
2. You can simplify your tech stack and enhance your team’s productivity
There is nothing more frustrating than having a list of front end features waiting to be implemented, while your back end team sits idle! We’ve seen this happen too often to mention, when front end and back end stacks are different from each other: only some developers feel comfortable tackling the web interface features, and that means you effectively operate on reduced capacity.
Now that you know that you can adopt C# / .NET for your front end programming, not only can you rationalise your tech stack, but you can also now utilise your team at its maximum capacity. Because code and libraries are shared, it’s easier for a traditionally back-end engineer to start learning the front-end code - and you now have a path to turning all members of your team into full stack developers. This will result in a huge productivity boost: suddenly all your existing C# dev teams can start handling the web front end work as well as back-end services.
1. Switching to Blazor maximises your options
The best thing about Blazor is that it opens up your options for taking gradual control of your front end. If you don’t feel your own team is ready to go all-in with web development yet, then you can hand over the initial Blazor implementation to an outsource team. With that stable basis, your own development team can start dipping a toe in by reviewing the code, troubleshooting it, and gradually enhancing it. This gives you the option to bring your front end completely in-house later down the line, as your team will now have the skills needed to confidently expand and maintain your web code.
0. (Special bonus reason!) Sharing model code between client and server eliminates a lot of headaches.
One perhaps unexpected although obvious with hindsight aspect that our in-house devs really enjoy: you can write data transfer objects and models in a shared dll and use them in both client and server. No need for reverse engineering an object model out of swagger definitions or any of those other pain points - your front end and your back end are literally talking the same language - priceless!
If you want to start with Blazor, consider collaborating with a partner like Oscore - we would be more than happy to explore your options and get you started on the path of C# web development. Reach out to us today to chat about your project and requirements.